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DESCRIPTION 

CIRCUIT COMPONENT INTERFACE 

5 This application claims priority to a U.S. Provisional Application entitled 

"System-on-a-Chip~1/' having Serial No. 60/216,746 and filed on July 3, 2000, and 
which is hereby incorporated by reference into this application as though fully set 
forth herein. 

Background Of The Invention 

10 1 . Field of the Invention 

The field of the present invention relates to electronic hardware, including 
virtual, component design. In particular, the field of the present invention relates to 
the interfaces between components. 

2. Background 

15 The methodologies for designing, testing and manufacturing integrated 

circuits (ICs) continue to evolve. Today, with the continually increasing complexity 
and density of ICs, designing for reusability is 1 becoming an overriding priority. One 
consequence of this priority is the increasing distinction of between the developers of 
potentially reusable functional component blocks, that when used with each other 

20 provide the foundation for an IC or the design of an IC, and the integrators of such 
blocks. A number of companies focus on the development of such functional block 
components. Some of the same companies as well as many others perform the 
integration and/or manufacturing of the ultimate ICs. 

One of the new developments in circuit designs is the advent of so-called 

25 virtual component blocks, which, from a general standpoint, are pre-designed and 
pre-hardened (or semi-hardened) circuit designs in software form (for example, in 
GDSII format), which can be readily re-used or recycled in different, larger circuit 
designs. An advantage of virtual component (or VC) blocks is that they reduce the 
time to design an overall circuit, and thereby, increase the speed to market. 

30 The breakdown of IC development into the design of discrete functional 

components, and the fact that there are many providers of such components, has in 
part been responsible for the creation of a need to have a standard interface for 
communicating between components. This is one of the goals of the Virtual Socket 
Interface Alliance (VSIA) Virtual Component Interface (VCI) Standard. A draft of this 
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standard, Standard 2 Version 1.0 (Working Revision (2/2/2000) is attached as an 
appendix. To meet this stated goal, which includes objectives of connectability, 
flexibility, and portability of component blocks, the VCI protocol, as outlined in the 
specification, has been developed with an eye towards simplicity. 
5 A preference for simplicity in the VCI protocol, in turn, has necessarily led to 

certain requirements to which component blocks that adopt the protocol must 
adhere. A first requirement is that one side of the interface is required to act as a 
master or initiator of a communication and the other side is required to act as a slave 
or target for the communication. As such, the design of the target interface has 

10 inherent differences from that of the initiator interface. Specifically, each side of the 
interface, by definition, comprises different logic to enable each side to perform its 
predefined role in the communication. Because of these complementary functions, 
the inputs and outputs on each side of the interface are also different from each 
other. The pins on each side of the interface to which connections are made 

15 represent a type of signal input or output that is generally specific to that side of the 
interface. 

Another requirement is that the VC Interface of a functional block be a 
unidirectional interface. Output pins on one side of the interface are connected to 
input pins on the other side of the interface, such that signals travel in only one 

20 direction for a given connection. 

Thus, functional components (including virtual components (VCs)) that 
include a VC interface can act only as targets or initiators in a point-to-point 
communication. As such, in any communication between two components, if one 
component is defined as a master, the other must be a slave, and vice versa. 

25 In any methodology for designing ICs based on predefined component blocks, 

one of the first steps is to specify, as a starting point, the component blocks that will 
be used as the foundation of the design. One such component block that is 
identified at this stage is the foundation block, a block that typically comprises a 
processor, some memory and a communication block. The communication block 

30 has the primary purpose of transferring data from one place to another, an in the 
context of IC design includes a bus connected to multiple I/O ports. The foundation 
block often manages the communication between most if not all of the other 
component blocks to be used in the IC. Because it includes a communication block, 
the foundation block typically includes on its edges a large number of ports, of which 

35 some are initiators and others are targets. Because of the requirements of standard 
protocols such as the VCI protocol, the type of interface at a particular location on 
the edge of a foundation block must be predefined. Thus, characterizing the 
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foundation block that is to be used for a given IC typically requires specifying a bus 
and the number, locations and types of ports on the edges of the block. For 
example, one common layout of ports for a foundation block is to position them 
evenly around the foundation block to provide for floor-planning flexibility. 
5 One of the next steps is specifying the placement of the component blocks, 

including the foundation block, to form the layout of the IC. In this process, chip 
designers try to minimize wire lengths between pins of different components and 
minimize the overall area or footprint of the IC. Increasingly, these connection 
distances are the greatest speed-limiting factor in efforts to increase the speed and 

10 performance of an IC. 

To assist in optimizing the layout of the IC, chip designers often use electronic 
design automation (EDA) software tools. The component blocks are automatically 
"placed" (i.e., given specific coordinate locations in the circuit layout) and "routed" 
(i.e., wired or connected together according to the designer's circuit definitions). The 

15 placement and routing software routines generally accept as their input a flattened 
netlist that has been generated by a prior logic synthesis process. This flattened 
netlist identifies the specific components from a component library, and describes 
the specific component-to-component connectivity. After this specific connectivity 
has been established, the physical design and layout software creates a physical 

20 layout file of the integrated circuit, including the physical position of each metal line 
(i.e., wire) and each via (i.e., metal transition between chip layers). 

Further explanation of a particular chip design process is set forth, for 
example, in U.S. Patent 5,838,583, hereby incorporated by reference as if set forth 
fully herein. 

25 Because the ports for the foundation block are specified before the layout 

process can be performed, the flexibility in component block placement is 
potentially limited by the locations and types of ports that have been specified. 
Essentially, the capability of optimizing a design footprint or achieving minimum 
connection lengths, and thereby, the ICs overall speed and performance, is 

30 compromised. 

A need exists therefore, for a way of optimizing for speed and performance in 
an electronic design without incurring the limitations inherent in a predefined 
foundation block or other functional block. 
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Summary Of The Invention 

The present invention, in one aspect, provides a systems and methods for 
designing an integrated circuit and for creating and using an androgynous interface 
between electronic components of an integrated circuit 
5 In one embodiment, an androgynous interface for communicating between 

electronic components having multiple connection points includes a circuit for a 
state machine and a plurality of pins connected to the circuit. The implementation of 
the state machine is preferably configured to perform as a target and an initiator of a 
communication. The plurality of pins preferably corresponds to a set of target signals 
10 for handling communication involving the component as a target and a set of initiator 
signals handling communication involving the component as an initiator. 

In one preferred embodiment, the pins are each unidirectional and include at 
least one input pin and at least one output pin. Preferably, the number of input pins 
is preferably equal to the number of output pins and the set of target signals is 
1 5 symmetric with the set of initiator signals. 

In another aspect, an electronic component includes the above-described 
androgynous interface. In yet another aspect, an electronic component that includes 
the above-described androgynous interface is modeled with the assistance of a 
computer. 

20 In another aspect of the present invention, an integrated circuit includes a bus, 

a plurality of functional blocks and a plurality of ports, where each port connects the 
bus to one of the plurality of functional blocks. Each of the plurality of ports 
preferably is designed to perform as both a target and an initiator of a 
communication. 

25 In yet another aspect, a computer-assisted model of an integrated circuit 

includes a bus model, a number of functional block models, and a corresponding 
number of port models, where each port model connects the bus model to one of the 
functional block models. Each of the plurality of port models preferably is designed 
to perform as both a target and an initiator of a communication. 

30 In yet another aspect, a method of designing an integrated circuit includes 

several steps. In one step, a foundation block for the integrated circuit is specified, 
including specifying the locations of multiple androgynous interfaces in the 
integrated circuit. In another step, one or more component blocks to comprise the 
integrated circuit are identified. In another step, the component blocks to form a 

35 layout of the integrated circuit are positioned in a manner that minimizes connection 
distances between functional blocks and between functional blocks and the 
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androgynous interfaces of the foundation block. In another step, the androgynous 
interfaces are set to perform as targets or initiators based on the layout. 

Further embodiments, variations and enhancements are also disclosed herein. 

Brief Description Of The Drawings 
5 FIG. 1 is a diagram of a computer system that may be used in connection with 

various embodiments of the invention as described herein. 

FIG. 2A is a diagram of a simplified integrated circuit as may be generated 
using a computer system such as shown in FIG. 1, before the component blocks have 
been placed on the integrated circuit chip. 
10 FIG. 2B is a diagram of a simplified integrated circuit as may be generated 

using a computer system such as shown in FIG. 1, after the component blocks have 
been placed on the integrated circuit chip. 

FIG. 3 is a diagram of a general process flow for a block-based integrated 
circuit design. 

15 FIG. 4 is a flow diagram detailing a preferred method of designing an 

integrated circuit. 

FIG. 5 is a table depicting an example of a set of signal designations 
implementing a symmetric androgynous communication interface. 

FIG. 6 is a diagram depicting communications system between two 
20 components that employs an androgynous interface between the components and a 
generic communication bus. 

FIG. 7 is a table depicting a mapping of signal designations to translate 
between a blocks using an androgynous virtual component interface protocol and a 
bus employing a System-on-Chip (SOC) protocol. 
25 FIG. 8 is a timing diagram depicting the operation of a system employing an 

androgynous communication interface that allows one side of the interface operating 
as an initiator to transition to a target interface type, and vice versa. 

Detailed Description Of The Preferred Embodiments 

Preferred embodiments will now be described, with reference as necessary to 
30 the accompanying drawings. First, however, additional information is provided 
concerning electronic design methodology and the use of automation (EDA) in such 
a methodology. 

Chip designers generally use a top-down design methodology, starting with 
hardware description languages (HDLs), such as Verilog® or VHDL, for example, to 
35 create an integrated circuit by hierarchically defining functional components of the 
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circuit, and then decomposing each component into smaller and smaller 
components. The components used in integrated circuits can be characterized as 
either functional or communication components or blocks. 

From the HDL or other high level description, the actual logic cell 
5 implementation is typically determined by logic synthesis, which converts the 
functional description of the block into a specific circuit implementation of the block. 
The circuit implementation typically exists as a netlist, comprising logic cells or 
component blocks and including one or more communication blocks. The 
component blocks are then placed and routed, resulting in a physical layout file. 

10 The physical layout file is generally used as a design "blueprint" for fabrication of the 
integrated circuit. At each stage of the design process, as well as at the fabrication 
stage, various tests may be run to ensure correct operability of the circuit design. 

FIG. 1 is a diagram of a computer system that may be used in connection with 
various embodiments of the invent/on as described herein. As shown in FIG. 1, a 

15 computer system 100 includes a computer 110 connected to a display 191 and 
various input-output devices 192. The computer 110 may comprise one or more 
processors (not shown), as well as working memory (e.g., RAM) in an amount 
sufficient to satisfy the speed and processing requirements of the system. The 
computer 110 may comprise, for example, a SPARC™ workstation commercially 

20 available from Sun Computers, Inc. of Santa Clara, California, or any other suitable 
computer. 

The computer 110 contains stored program code including, in one 
embodiment, a block floorplanner 120, a block placer 130, a logic synthesizer 135 
and a routing space estimator 140. The block floorplanner 120 provides for the 

25 definition of block functions, block regions, and constraints on these for the purpose 
of interactive floorplanning operations by the circuit designer, and the control of 
placement operations of the block placer 130. The block placer 130 determines the 
placement of cells within blocks according to the constraints defined by the circuit 
designer. The routing space estimator 140 estimates routing space required for 

30 routing the blocks, given the placement of such blocks by the block placer 1 30. 

In support of the above-mentioned system components, a chip floorplanner 
150, global/detail router 160, standard cell placer 170, logic synthesizer 180, and 
HDL editor 190 may be usefully employed. Operation of the chip floorplanner 150, 
global/detail router 160, standard cell placer 170, logic synthesizer 180, and HDL 

35 editor 190 is conventional, as the design of these components is well known in the 
art of electronic design automation. Commercially available examples of these 
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system components are Preview™, Cell3™, QPlace™, Synergy™, and Verilog®, 
respectively. 

The computer 110 is preferably coupled to a mass storage device (e.g v 
magnetic disk or cartridge storage) providing a layout database 195 with which the 
5 foregoing system components interface. The layout database 195 may be 
implemented using the EDIF database standard. The computer 110 may also 
comprise or be connected to mass storage containing one or more component 
libraries (not shown) specifying features of electrical components available for use in 
circuit designs. 

10 Referring now to FIG. 2A, there is shown a block illustration of a simplified IC 

200 before the design of the IC has been completed, wherein a foundation block 202 
and a number of peripheral component blocks B1, B12 have been specified, but 
where the actual connections between blocks remain undetermined. In actual, more 
realistic integrated circuit designs, the integrated circuit 200 would be far more 

15 complicated. However, FIG. 2A is useful for purposes of illustration. The foundation 
block preferably includes a processor 204, a memory 206, several other component 
blocks, A1, ... A5, and a communication block comprising a bus 208 and twelve 
androgynous ports 210. The ports 210 are androgynous because they may be 
configured as targets or initiators in the communications interface after the layout of 

20 the IC 200 has been finalized. Finalizing the layout preferably requires placing the 
other IC components B1,..., B12 on the chip. The foundation block 202, including 
its components (the processor 204, the memory 206, and components, A1 through 
A5), and the other peripheral component blocks are preferably fully characterized in 
the layout database 195. 

25 FIG. 2B is a diagram depicting the results of placing the component blocks, 

B1 through B12 on the chip. Preferably, the blocks have been placed in a manner 
that is optimal with respect to location and the lengths of the connections to the ports 
on the foundation block. The placement, however, does not account for an interface 
type for a particular port on the edge of the foundation block because each port is 

30 androgynous and the same as every other port on the block. That is, no port is 
"hardened" to perform as a target or an initiator. Thus, the placement of the blocks, 
B1 though B12 is preferably optimized towards other considerations. 

FIG. 3 is a diagram of a general process flow 300 for a block-based circuit 
design, illustrating some of the various levels of integrated circuit design abstraction 

35 as described above. As illustrated in FIG. 3, a register transfer logic (RTL) file 301 in 
the form of an HDL file or other high level functional description undergoes a 
specification (floor planning and part assignment) process 302. In this process 302, 
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component blocks are identified from a component library 306 to perform specific 
functions set out in the RTL file 301. The component blocks are preferably 
predefined, and although one or more may be based on a customized design not 
stored or only recently stored within the library 306. 
5 In the next step 303, a form of logic synthesis performed, where in one 

preferred embodiment, the functional description of the connections between the 
components is converted into a specific connection implementation which may be 
stored in the form of a netlist file 304. As part of this compile process 303, the 
component library 306 is generally referenced, which stores information concerning 

10 the androgynous interface, and the characteristics of the components which are 
needed in order to determine their functional connectivity. The netlist file 304, as 
previously noted, generally identifies the component blocks from the library 306, 
and describes the specific component-to-component connectivity. 

By application of a physical design process 309 shown in FIG. 3, the 

15 component blocks of the netlist file 304 are then placed and routed, resulting in a 
layout file 310. The component library 306 is utilized in this process stage in order 
to obtain information concerning the sizes of the components that may be present in 
the netlist file 304. Previously, this information includes interface specifications, 
such as the whether the numbers and locations of the interfaces, whether each 

20 interface is a target or initiator, the number of pins and their signal assignments. As 
described in the background section above, the placement and routing operation is 
then performed and may be automated in, a manner to optimize the ICs ultimate 
performance by minimizing connection lengths and the ICs overall footprint. This 
placement and routing process however, adheres to the interface specifications 

25 obtained from the component library 306. 

From the layout file 310, a verification process 312 may be run, as further 
illustrated in FIG. 3, resulting in a mask file 315 in, for example, a GDSII or CIF 
format. The mask file 315 may be provided to a foundry, and contains enough 
information to allow the foundry to manufacture an actual integrated circuit 

30 therefrom. 

In one aspect, systems and methods are provided in connection with certain 
embodiments disclosed herein for designing integrated circuits and for creating and 
using an androgynous interface between electronic components of an integrated 
circuit. 

35 FIG. 4 details a preferred method 400 for designing an IC such that the layout 

is optimized without having to adhere to specifications regarding the whether a port 
. is a target or an initiator. In a particular embodiment, the ports that are unspecified, 
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as to being targets or initiators, are on the IC's foundation block, which includes a 
processor, memory, and a communication block that specifies a bus and a plurality 
of ports that will in operation perform as either targets or initiators. In a first step 
402, the communication block (or the complete foundation block) is specified. This 
5 communication block may be extracted from the component library as part of a logic 
synthesis operation or may be originally designed. The communication block 
preferably is specified with a particular bus configuration and footprint on the IC 
chip. The communication block is further described by a fixed number of ports and 
particular locations around the block. Each port is defined to be androgynous such 
10 that at this stage of design, it can be later adapted or bound to perform as a target or 
an initiator. 

In a next step 404, other component blocks are specified. Like the 
communication block, these other component blocks are preferably identified as part 
of a process or program to synthesize logic and produce a netlist file. Because steps 
15 402 and 404 relate to the specification of different components, in an alternative 
embodiment, the steps 402, 404 may be switched in order or performed at the same 
time. 

In a next step 406, the blocks are laid out on the IC. In this step 406, which 

may be performed automatically, the layout of the blocks on the IC is optimized to 
20 keep connection lengths between input and output pins on different block to a 

minimum. Furthermore, the blocks are preferably organized such that the overall 

area of the IC is also minimized. 

In a next step 408, each of the androgynous interfaces on the communication 

block are adapted to perform as a target or an initiator based on the required type of 
25 interface for the block connected to the interface by the layout provided by step 406. 

In an alternative embodiment, the androgynous interface is designed such that ports 

on the IC perform, in an operational environment, as targets and initiators of 

communications. 

A number of methods exist to adapt the androgynous interfaces to perform as 
30 either targets or initiators. In one preferred embodiment, the interface logic includes 
configuration registers to enable the setting of one side of the interface as a target or 
an initiator. When configured as a target, the sets of pins are configured to receive or 
transmit signals according to the protocol for the target. When configured as an 
initiator, preferably the same set of pins is used to transmit and receive signals 
35 according to the protocol for an initiator. 

In another embodiment, an interface type parameter is input to a logic 
synthesis operation that synthesizes away the state machine configuration that is not 
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used for actual operation of the IC. Preferably, what remains is the state machine for 
the interface that is selected using the logic synthesis parameter. Alternatively, the 
parameter is used to generate the logic for the selected interface type. The 
androgynous interface, however, is configured such that the same pin connectivity is 
5 maintained regardless of which interface type is selected. 

In another embodiment, a pin on the androgynous interface is tied to a logical 
1 or 0 based on whether the interface is to operate as a target or initiator. The logic 
to control the interface is therefore preferably configured to operate as a target or 
initiator depending on the value of the input received using the additional pin. 

10 The androgynous interface preferably exhibits certain general characteristics. 

On a basic level, the androgynous interface includes logic and I/O structure to 
perform both as a target or an initiator. That is, the interface includes a set of pins, 
where each pin has a signal designation, a signal direction, and a specification for a 
corresponding pin to which it connects. Thus, the set of pins includes a sufficient 

15 number of pins to include alt of the signals that are received or transmitted by a 
target and all of the signals that are received or transmitted by an initiator. In one 
embodiment, each pin in the set of pins is dedicated to perform a target function or 
an initiator function. In an alternative embodiment, some or all of the pins have 
target or initiator signal specifications that depend on a setting of the interface to 

20 perform as one or the other. Optionally, this setting is dynamic, such that the 
interface switches roles from one communication to the next. As another option, the 
setting is part of an initialization of the device on start-up. Alternatively, the setting is 
hardwired or is otherwise fixed in the interface )og)c. Advantageously, in the 
configuration in which the pins are configurable with respect to interface type, fewer 

25 pins are employed to implement the interface. 

As a specific preferred characteristic, the androgynous interface includes the 
same number of input lines as output lines. That is, the set of pins includes equal 
numbers of input pins as output pins. Applying this criterion, when an androgynous 
interface is set for use as a target or initiator, fewer, if any, pins need go unused or be 

30 tied off. 

As a more specific preferred feature, the androgynous interface is a symmetric 
interface. With this feature, the interface includes the same number of input pins as 
output pins. Furthermore, each pin includes a signal designation in a role as a target 
pin and a signal designation in a role as an initiator pin. In addition, the 
35 corresponding pin to which a given pin connects preferably has the same dual 
functionality, but in particular instances always employs the signal designation that is 
complementary to that of the given pin. 
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In each of the above embodiments, the logic used to implement the 
androgynous interface may be fully hardware implemented, may include software- 
coded elements or may be fully implemented in software using a general or special 
purpose processor. 

5 In a preferred embodiment of the symmetric androgynous interface, the 

interface is an extension of the unidirectional interface described in the VSIA VCI 
Standard. In one embodiment, the androgynous interface is the virtual component 
(VC) interface that includes hardware that performs the logic set out in the VSIA. In 
another embodiment, the androgynous interface comprises generalized computing 

1 0 hardware that is loaded with the protocol to execute as a VC interface. 

Therefore, the androgynous interface includes a set of signals that follow the 
VC interface protocol, but can be used either as an initiator, a target or both. This 
permits the number of VC interfaces to be defined later during the foundation block 
integration, and then even later define the size and type of each interface. 

15 FIG. 5 depicts a preferred embodiment of a signal map for a symmetric 

androgynous interface adapted from the Basic VC interface (BVCI) disclosed in the 
VSIA VCI Standard. To adapt the BVCI to be a symmetric androgynous interface, the 
names of the signals are reversed, to consider "R_" as received instead of response. 

In the BVCI, the Error signal does not exist, but is specified for the 

20 androgynous VC interface. Furthermore, the Wrap, Const, Contig signals in BVCI are 
assumed to be part of the Cmd signal in the androgynous VC interface depicted in 
FIG. 5. Additional return signals are defined for androgynous interface, such as Cmd, 
Clen, Cfix, which do not have return signals in the BVCI. However, the specification 
of these signals enables both sides of the androgynous VC interface look the same, 

25 and therefore creates an androgynous interface that is symmetric. The target and 
initiator sides of the interface have the same number of pins, the same connections, 
and pin designations. 

In a preferred embodiment, the interface that first issues a data valid signal 
preferably becomes the initiator. The other side then automatically becomes the 

30 target and acknowledges the data valid signal. The target then may issue a data valid 
signal in response to each acknowledged data valid signal it receives. The initiator 
then issues an ACK signal. The end of the packet on the data valid side preferably is 
sent with an EOP signal, and the end of the response packet is preferably sent with 
an EOP signal. The response EOP signal preferably indicates that the interface Is 

35 waiting to determine who next is the initiator. 

A key advantage offered by this symmetry is that the state machine logic is 
essentially the same regardless whether the interface acts as a target or initiator. Little 
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additional logic is needed to enable the interface to operatively perform as a target or 
initiator. 

In another alternative embodiment of a symmetric androgynous interface, the 
interface is integrated into bus wrappers, including a target wrapper and an initiator 
5 wrapper. The bus wrapper defines a package that translates the protocol for a 
particular bus type into an androgynous VCI protocol. Thus, functional components 
that adhere to the androgynous protocol can communicate using any bus that 
includes an androgynous VCI bus wrapper. FIG. 6 depicts a configuration 600 for 
communicating between two components 602, 604 that employ a VC interface. A 

10 component block 602 performs as an initiator and includes an initiator interface 606. 
Another component block 604 correspondingly performs as a target and includes a 
target interface 608. The two components 602, 604 communicate via a bus 610, 
that may be of any convenient type, by virtue of an initiator wrapper 61 2 and a target 
wrapper 614 that translate the signals in the VCI protocol to the bus protocol and 

15 vice versa. The initiator wrapper 612 preferably includes a VCI target interface 616, 
a bus master interface 618, and interface-to-rnterface translation logic. 
Correspondingly, the target wrapper 614 includes a VC initiator interface 620, a bus 
slave interface 622, and interface-to-interface translation logic. 

In one preferred embodiment, the mapping performed by the target and 

20 initiator wrappers 614, 612 implements a translation of the Systern-on-Chip (SOC) 
standard to an androgynous symmetric adaptation of the VC interface, and vice 
versa. In this embodiment, in relation to FIG. 6, the bus 610 complies with the SOC 
standard. FIG. 7 is a table depicting an example of the signal mapping for these two 
interfaces. 

25 The androgynous VC interface is similar to the SOC standard in that first, both 

preferably use a four-wire protocol. In the androgynous interface, a req->gnt signal 
is used for writes from initiator to target and a r_req -> r_gnt signal is used for the 
return reads from the target to the initiator. Second, the interface standards have the 
same EOP and Cmd (command) structure. Third, the interface standards preferably 

30 have the same data and address structure. 

With respect to the differences, preferably no byte enables, non-sequential 
addressing, or chaining modes are used. Also, an r_cmd signal, an r_error signal and 
an r_d_size signal are added to make the VC interface symmetric. Further, the 
androgynous interface preferably uses an additional parameter MASTER that may be 

35 set. If MASTER is set, then the interface to the functional block is a master. The 
wrapper for the interface then employs the mapping on the left side of FIG. 7. If 
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MASTER is not set, then the interface for the functional block is a slave, and the 
wrapper for the interface employs the mapping on the right side of FIG. 7. 

Optionally, to dynamically change between initiator and target protocols on 
one interface, two signals may be passed between the VCI wrappers: 

5 ITT I/l 

RJT <- IT 

IT -> RJT 

The IT signal is preferably set by the side that is the initiator, and the target preferably 
responds by clearing its IT signal. Subsequent requests are then considered errors if 

10 the responding IT signal is set or the wrapper's IT signal is cleared. This additional 
handshake protocol is optionally used in other embodiments. 

FIG. 8 depicts an example of transactions between two blocks A and B. FIG. 
8 depicts a window in time when the androgynous interfaces are in an idle state, 
preferably enabling the interfaces to switch interface types, from initiator to target 

15 and vice versa. Initially, Block A is the initiator and transmits a request to Block B. 
Block B then responds to the request to complete the transaction. Before the 
issuance of the request and after the response is received, the interfaces for the 
blocks are in an idle state. It is during this time that the interfaces may switch 
interface types. After the response by Block B, the types are switched, as evidenced 

20 by the issuance of a request by Block B, demonstrating that it is now an initiator. 
Only after Block A completes the transaction by issuing a response to Block B's 
request do the interfaces return to an idle state, enabling an interface type. switch by 
the two interfaces. 

As discussed above, the androgynous interface alternatively is designed to 
25 allow both interface types to be available in one physical interface for any given 
communication operation. A single physical interface potentially avoids issues that 
arise due to the fact that two interfaces take up actual loading on the bus and 
typically require additional pins. Two separate interfaces, however, are optionally 
employed if both target and initiator operations are needed at the same time. 
30 In other embodiments, the androgynous interface may be implemented as a 

bi-directional interface, where signals for a given pin are both input and output 
signals. The androgynous interface may be adapted to other implementation of the 
VSIA VCI Standard including the Peripheral and Advanced VC interfaces. 

In another embodiment, the use of an androgynous interface may be 
35 employed with pin unscrambling systems and methods as described in our 
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copending application entitled "Adaptable Circuit Blocks for Use in Multi-Block Chip 
Design/' having attorney docket number 260/089, and filed January 18, 2001. 

The above-described embodiments describe the implementation and use of 
androgynous interfaces in the context of component blocks that communicate with 
5 or between integrated circuits. However, the generalized embodiments of the 
androgynous interface are preferably used in other contexts that involve 
communication blocks that transfer information from one point to another. In the IC 
context, the communication block includes a bus (either bi-directional or 
unidirectional and employing multiplexers) and multiple androgynous ports off of the 

10 bus. In other contexts, the communication block may be a crossbar-switch, a hub, a 
router, a network, or a memory such as a FIFO that is employed to transfer data. In 
these other contexts, the communication block includes a set of appropriate 
androgynous interfaces. Thus, the androgynous interfaces disclosed herein may be 
generally applied to other areas of electronic communication. 

15 While preferred embodiments of the invention have been described herein, 

and are further explained in the accompanying materials, many variations are 
possible which remain within the concept and scope of the invention. Such 
variations would become clear to one of ordinary skill in the art after inspection of 
the specification and the drawings. The invention therefore is not to be restricted 

20 except within the spirit and scope of any appended claims. 
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1. Virtual Component Interface (VCI) Background 

This standard is the result of the work of the On-Chip Bus (OCB) Development Working Group (DWG) of 
the Virtual Socket Interface Alliance (VS1A). The charter defined for the OCB DWG was to define on-chip 
bus -related specifications for the design, integration, and test of multiple functional blocks on a single 
piece of silicon. 

Two generic audiences are targeted: Providers of functional blocks and Users or Integrators of these blocks. 
For the Providers of functional blocks, the standard defines the protocols and interfaces their Users require 
for effective reuse of the blocks in an integrated product design. For the Users of functional blocks in 
compliance with this standard, it depicts the information these Users will need to properly evaluate, 
integrate, and verify one or more functional blocks in a design. 

The overall objective is to obtain a general interface, such that Intellectual Property (IP), in the shape of 
Virtual Components (VC) of any origin, can be connected to Systems-on-Chips (SoC) of any chip 
Integrator. In this manner, VCs arc not limited to one-time usage by their designers. They can be re-used 
over and over. Such re-use of VCs would also apply to VC Providers or to (external) System Integrators. 

Early in the existence of this DWG it became clear that picking an existing bus or defining a new one 
would not be the right way to go. First of all, System Integrators will stick to their own bus for a relatively 
long time, if only to allow for connection of their existing VCs without modification. Connecting new VCs 
via a bus-to-bus bridge is expensive in timing and in silicon footprint. Furthermore, all existing buses are 
rather good for their particular usage. Inventing yet another one does not make much sense. Thus there 
would be little chance of such a bus being accepted. 

For these reasons, the working group decided to define an interface rather than a bus. This interface can 
then be used as a point to point connection if one is needed and additionally as an interface to a bus 
connector if that is what is desired. 

1.1 Goals 

The following were considered primary goals in defining the VCI. 

1 . Must enable maximum portability of a VC 

- VCI-compliant VCs should inter-operate with OCBs of varying protocols and 
performance levels. 

- VCJ should not dictate the integration methodology, i.e.VCJ can be used as a point-to- 
point interface without an OCB, andean be connected to different OCBs with automated 
methods, or with hand-crafted wrappers. 

2. Should not require modification of VCI-compliant VCs in order to connect to a different VCI-compliant 
VCorOCB. 

- Some combinations of VCI-compliant VCs and OCBs may result in reduced features or 
performance, but must still function correctly and reliably. 

3. Simple and efficient to implement with clear and easy to understand protocol 

- Necessary for wide acceptance. 

4. Design a compatible family of VC Interfaces (i.e. Advanced VCI, Basic VCI, and Peripheral VCI) 

- This enhances inter-operability choices for the System Chip designer, and design 
opportunities for the VC designer. 

5. Protocol must be fully defined 
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- This includes full enumeration of possible interactions together with statements on 
allowed / disallowed behavior. However, it is essential for wide adoption that there be 
some mechanism for extending the protocol. 

6. Few optional signals 

- Minimize the number of truly optional signals to minimize the complexity ofVCI 
compliance checking. However, signals such as data and address lines and supported 
transfer widths may be parameterizable and/or scalable. 

1.2 Key Assumptions 

This section describes the assumptions that were made in defining the VCI. 

1. Initiator/Target connections are point-to-point and unidirectional. 

- Both multiplexed and tri-state OCBs can be supported by allowing the OCB wrappers 
to implement the OCB transceivers. Separate unidirectional nets are simpler to handle, 
and this circumvents the requirement for arbitration in the VCI protocol. 

2. Initiator can only present requests; Target can only respond 

- If a VC needs both capabilities, implement parallel Initiator and Target interfaces. 

LA combined (peer-to-peer) protocol is much more complex to define and implement 
(due to interface arbitration requirements). 

• Some OCB architectures can take advantage of the separate initiator and target 
interfaces by connecting the VC Initiator interface to a System OCB whereas the 
(separate) VC Target interface might connect to a Peripheral or Configuration OCB 
(a bus for loading device configurations). 

• Finally, the parallel interface is simpler to model and offers possible performance 
advantages using simultaneous transfers. 

- Limited fundamental Read / Write requests. 

• Peripheral VCI is limited to read and write 

• Basic VCI includes Nop and read lock. 

3. Address / Data widths are determined by VC requirements 

- OCB Target's Initiator should scale its address /data widths to match Target 

4. The standard should ensure that any required data and address storage in the wrappers is minimal. 

- Anything more than minimal timing overhead is deemed unacceptable and would 
negatively impact acceptance. 

5. Clock domain crossing will not be visible at the interface 

- Interface is fully synchronous. Clock domain crossing is considered a design guideline 
for wrapper or VC implementation. 

1.3 Document Conventions 

b == number of bytes in a cell 

n == most significant bit of address field 

m = least significant bit of cell-address 

k = Number of bits in the packet length field 

q = Number of bits in the packet chain length field 

E = Number of bits in the error extension field 

Timing constraints: 

Early: Signal is Valid within 20% of the clock cycle from the rise of the Clock signal 
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Middle: Signal is Valid within 50% of the clock cycle from the rise of the Clock signal 

Late : Signal is Valid within 80% of the clock cycle from the rise of the Clock signal 

1 .4 Document Organization 

The Standard begins with defining the basic characteristics of the VCI. The different-complexity interfaces 
are described in detail next, starting with the simplest one, the Peripheral VCI. The PVCI and BVCI 
sections are designed so that they can be read independently, i.e. if a reader wants to know about to use the 
PVCI, he does not need to be familiar with the BVCI. After the interface descriptions, some design 
guidelines are given. VCI Transaction Language section will be included in the standard version 2 2.0. 
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2. VCI Characteristics 

2.1 VCI Definition 

The Virtual Component Interface or VCI is an interface rather than a bus. Thus the VCI specifies: 

1 . A requests-response protocol. 

2. A protocol for the transfer of requests and responses. 

3 . The contents and coding of these requests and responses. 

The VCI docs not touch areas as bus allocation schemes, competing for a bus, etc. 

There are three complexity levels for the VCI: Advanced VCI, Basic VCI, and Peripheral VCI (A VCI, 
DVC1, and PVCI respectively). The current version of the VCI standard defines the Basic VCI and the 
Peripheral VCI. The Advanced VCI will be added later. The Basic VCI defines an interface, which is 
suitable for most applications. It has a powerful, but not overly complex protocol. The Advanced VCI will 
add more sophisticated features, such as treads, to support high performance applications. The Peripheral 
VCI provides a simple, easily implementable interface for applications, which do not need all the features 
of the Basic VCI. The Peripheral VCI is a subset, and the Advanced VCI is a superset of the Basic VCI, 
and all those interfaces are designed to be compatible with each other. 

2.2 Point to Point Usage 

As an interface, the VCI can be used as a point to point connection between two units called the Initiator 
and the Target, in which the Initiator issues a request and the Target responds. The VCI can also be used as 
the interface to a "wrapper", a connection to a bus. This is how the VCI allows the Virtual Component to 
be connected to any bus (See section 2.4).' Basic point to point usage is depicted below in Figure 1 . 



Initiatoi 


request 


Targe 


— . — »». 





Figure 1..VCI Is a Point to Point Connection 

This interface is very simple indeed while protocol and coding are concerned. Nevertheless, the interface 
contains many sophisticated features, as will be explained in further chapters of this standard. Its simplicity 
is the reason for the small footprint, and the high bandwidth. 
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2.3 Split Protocol 

Basic VCI and Advanced VCI make use of a "split protocol". That is, the timing of the request and the 
response are fully separate. The Initiator can issue as many requests as it sees fit, without waiting for the 
response. The protocol does not prescribe any connection between issuing of requests and arrival of the 
corresponding responses. The only thing specified is that t he order of responses corresponds to the order of 
requests. 

In the Advanced VCI requests may be tagged with identifie rs, which allow such requests and request 
threads to be interleaved and even allows res ponses to arrive in a different o rder. Responses shall bear the 
same tags issued with the corresponding requests, such that the relation can be restored upon the reception 
of a response. Additional details will be provided as the Advanced VCI is standardized. 

In the Peripheral VCI, no split protoco l is used, and each request must be followed by a response, before 
the Initiator can issue a new request. This srniplIllc^iWis~f6r supporting simple peripheral buses. 

2.4 VCI Usage with a Bus 

The VCI can well be used as the interface to a 'Svrapper" , which means a connection to a bus. This is how 
the VCI allows the VC to be connected to any bus. An Initiator is connected to that bus via a bus initiator 
wrapper. A Target is connected to that bus via a bus target wrapper. Once the wrappers for the bus have 
been designed, any VC can be connected to that bus, as depicted below in Figure 2. The wrapper and the 
VCI-boxes (the non-shaded area) in the picture together correspond to the traditional bus interface within 
both the initiator and the target. The whole interface will, again, function as a point-to-point connection. Of 
course, the use of VCI does not prevent using native bus components at the same time. In fact, the 
presented use of VCI is completely transparent to the bus system. 

It is intended that OCB suppliers will provide VCI wrappers to their proprietary bus, or EDA vendors will 
provide tools to create such wrappers automatically. This will free the IP Provider from having to 
understand the details of many buses. 




VCI target 




VCI 

Point to point 



VCI 

Point to point 



Bus master 



I 



initiator wrapper 

target wrapper 

Any Bus 



I 

VCI initiator 



Bus slave 



Figure 2. Two VCI Connections Used to Realize a Bus Connection 
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2.5 Notes 

1 . The "Initiator" and "Target" are simpler than their equivalents directly, connected to a bus. The VCI 
initiator and the VCI target are much simpler than the bus initiator and target interfaces. The bus 
interface, though, is not removed. It is in the wrappers. 

2. The wrapper contains not much more than the bus interface, which is needed anyway when connecting 
(no matter what) to the bus and to the VC interface block. 

3. The two blocks marked "vci initiator" and the two blocks marked "vci target* in Figure 2 are very 
simple. They do not add much to the total footprint or timing. This is especially so, as some logic is 
needed quite often anyway to connect the actual functionality of Initiator and Target to their bus 
interfaces, h is merely (he vcijnitiator - vcijarget interface that is standardized in the VCI. 
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3. Peripheral VCI 
3.1 Overview 
3-1.1 Scope 

This section defines the first member of the VCI family, the Peripheral Virtual Component Interface 
(PVCI), which can be used in conjunction with peripheral on-chip buses as defined in the VSI A OCB 
Specification 1 1 .0, and for point-to-point connections between Virtual Components. The PVCI is a subset 
of Basic VCI as the Basic VCI is a subset of the Advanced VCI. 

3.1.2 Organization 

This section contains the following chapters: 

• Chapter 3. 1 provides an overview for the section 

• Chapter 3.2 gives a technical introduction to Peripheral VCI 

• Chapter 3.3 provides a detailed description of PVCI signals 

• Chapter 3.4 defines the PVCI protocol 
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3.2 Technical Introduction to Peripheral VCI 
3.2.1 Initiator - Target Connection 

As shown in Figure 3 below, the request contents and the response contents are transferred under control of 
the protocol, a simple 2-wire handshake. 



Initiator 


contents 


Target 


request 

^ handshake 


■M 

contents 


response 



Figure 3. PVCI; The Bequest and Response Contents are controlled by a Simple Handshake 
3.2.2 The Handshake 

Note that in Figure 3, the handshake arrow is a double pointed showing that signals in both directions are 
involved. ('Signal' here is synonymous to l net', 'wire 1 or l port\) The handshake protocol is aimed at 
synchronizing two blocks by transferring control information in both directions. The contents-arrow points 
one way only. The PVCI handshake signals arc called VAL and ACK, as for Valid and Acknowledge. 

Request-contents flow from Initiator to Target, response-contents flow from Target to Initiator. The 
handshake protocol is introduced below. (See Figures 4 and 5.) Note that the delays are exaggerated in the 
figures. The triggering events for each transition are expressed with arcing arrows. 

Sample Sample Sample 

contents contents contents 



• ■ < 



VAL 

contents 
ACK 




Figure 4. The Control Handshake (Asynchronous ACK) 



In Figure 4: 

• Vertical dashed lines show rising c)ock edges. 
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• VAX. shows "at the next rising edge, contents can be read". No actual timing is specified here! 

• ACK, while VAL is active at the rising edge of the clock, shows that the contents were read by target, 
or contents are available to be read from the target. This means the end of the transaction. 

VAL and contents must be maintained until ACK has become asserted and there is a rising edge of the 
clock. As indicated in Figure 4 (right hand side), maintaining the VAL signal in asserted mode for another 
clock cycle after ACK = 1 means that another request is waiting. 

The ACK can be either generated asynchronously of the VAL as in the Figure 4, or set synchronously at 
the rising edge of the clock as in the Figure 5. The synchronous ACK can be set at the next clock cycle 
after Valid, or later. (A slow reaction, or late ACK.) If asynchronous ACK is used, special design 
considerations are needed to make suie that the ACK is stable at the rising clock edge. This means that if 
the ACK is not driven directly by a flip-flop, it must be generated from the VAL signal in the target with a 
minimum amount of logic and wire delay. 




ACK 



Figure 5. Fully Synchronous Control Handshake: ACK Late by 2 Cycles 
The Default Acknowledge 



A "default acknowledge" is permitted on top of this protocol. Since the acknowledge-signal is only 
sampled when VAL = 1, it can be asserted (long) before it is needed. Such an early ACK has no influence 
on the protocol behavior. The early ACK is merely "don't care" (the signal is not being considered, if 
VAL is not active). The acknowledge-signal can even be tied permanently active, if the target is always 
able to serve the request in one clock cycle. 

3.2.3 Request and Response Contents 

Each handshake is used to transfer a cell across the interface. Cell size is the width of the data passing 
across a VCI. It will typically be 1,2 or 4 bytes. The cell is synonymous to data word, and the cell size to 
word length. The cell size is always the same as the size of the particular VC Interface. The Figure 6 shows 
the signal groups of the PVC1 belonging to the request and response. The request contents are the Valid, 
cell-address, byte-enables within the cell, data to be written, command signal indicating whether we are 
reading or writing data, and end-of-packet, indicating the end of a burst of several cells (see the description 
later). The response contents are the acknowledge, response error, and the data read from target. The 
initiator interface is similar, except that the signal directions are opposite. 
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Figure 6. Peripheral VC Interface - Target 



3.2.4 Main Peripheral VCl Features: 

• Up to 32-bit Address 

• Up to 32-bit Read Data 

• Up to 32-bit Write Data 

• Synchronous 

• Allows for 8-bit, 1 6-bit, and 32-bit devices 

• 8-bit, 1 6-bit, and 32-bit Transfers 

• Simple packet, or 'burst' transfer 

• Optional Free-BE mode allows transfer of any combination of bytes of a word 

• Least Significant Bit is bit "0" 

• PVCI has no explicit Endianness 

• Natural byte alignment 
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3.3 Signal Definitions 

This chapter defines the PVC1 signals. First, the signals are summarized in 

table format A textual definition of each signal follows. All signals included in Table 1 below are assumed 
to be active-high signals unless explicitly indicated otherwise. It is recommended that all signal outputs 
are stable before Early. It can be assumed that all inputs are stable before Late. 



System Signals 













CLOCK 


System 


Initiator/Target 


i 


Supplied by the system. Interface is 
synchronous to the rising edge only. ■ 


RESETN 1 


System 


Initiator/Target 


i 


Supplied by the system. Active low reset. De- 
asserts VAL and ACK. 



Handshake, Flow Control, and Shaping 







BMP 




|^^^^ 




VAL 


Initiator 


Target 


1 


This pair of signals provides flow control for a 
cell transferring across the VC Interface, and 
validates all signals associated with that cell. 
VAL— 1 : indicates that the initiator has a cell 
available. 

ACK=1 : indicates that the target can 
complete the operation on the cell. 
The cell is therefore transferred when 
VAL=ACK=1 


ACK 


Target 


Initiator 


1 


EOP 


Initiator 


Target 


1 


EOP=l indicates that the current cell is the 
last one in a series of cells accessed at 
contiguous addresses. Can be interpreted as 
an inverted burst signal. 



Operation Information 





as 








ADDRESS 
[N-1:0] 


Initiator 


Target 


N 


N is a parameter based upon the capabilities 
of the target and is defined and fixed at the 
time of component instantiation. The most 
significant bit of the address is carried by bit 
W-l , and the least significant bit is carried by 
bit 0. See 3.3.3 for use of low-order address 
bits. 


RD 


Initiator 


Target 


1 


This is a single bit code giving the operation 
type: 

READ=1 : Read data from the target 
peripheral 

READ=0: Write data to the target peripheral 


BE 

[b-l:0 |0:b- 
1] 


Initiator 


Target 


b 


This is a field with b-bits, one for each byte, 
which indicates which bytes of the word 
being transferred are enabled. The usage 
restrictions of BE are listed in 3.4.3. 
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WDATA 
[8b- 1:0] 


Initiator 


Target 


8b 


This is the data, which is transferred with 
write operations to the target. For the 
Peripheral Interface, the allowed values of b 
are 4, 2, 1. Bit 8b-l is the most significant bit, 
and bit 0 is the least significant bit. Byte [8b- 

x .oo-oj represents uic jiiuoi MgiiiiiidJU uyic 

For VCs supporting a data size which is not a 
power of two, the next larger supported b will 
be used with the unused bits tied to logic zero. 
For example, a 12-bit device must use a 16-bit 
wide PVCI with the 4 Most Significant bits 
tied to logic zero. 


RDATA 
[8b- 1:0] 


Target 


Initiator 


8b 


This is the data, which is returned from the 
target with read operations. Since the 
peripheral interface has no pipelining, 
RDATA is validated by the target when it 
asserts ACK. It is defined in the same way as 
WDATA above. 


RERROR 
[E:0] 


Target 


Initiator 


E+l 


Indicates error in transfer. Optional error 
extension bits indicate nature of the error. E is 
defined by parameter ERRJJEN. It is zero or 
more 



Table 1: Peripheral VCI Signals 



3.3.1 System Level Signals 
Clock 



Signal Name: Clock 

Signal Abbreviation: CLOCK 

Polarity: Active at Positive edge 

Driven By: System 

Received By: VCI Initiator, VCI Target 

This signal provides the timing for the Virtual Component Interface and is an input to both the initiator and 
target that are connected via the PVCI. All initiator and target output signals, unless otherwise specified, 
are asserted/de- asserted relative to the rising edge of CLOCK and all initiator and target inputs are sampled 
relative to this edge. 



Reset 



Signal Name: 
Signal Abbreviation: 
Polarity: 
Driven By: 
Received By: 
Timing: 



Reset 
RESETN 
Asserted Negative 
System 

VCI Initiator. VCI Target 
Asserted > 8 clock cycles 



This signal is used during power-on reset and is used to bring the PVCI to an idle or quiescent state. This 
idle state is defined as the PVCI state in which: 

1 . The VAL signal is de-asserted 

2. The ACK signal is de-asserted 
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The system must guarantee that RESETN is asserted for at least eight cycles of CLOCK (More if 
RESETLEN parameter is set.). 



3.3.2 Control Signals 

Valid 



Signal Name: Valid 

Signal Abbreviation: VAL 

Polarity: Asserted Positive 

Driven By^ VCI Initiator 

Received By: VCI Target 

Timing: Asserted at rising edge of CLOCK until ACK = 1 and next rising edge 
of CLOCK. 



The VAL signal is driven by a VCI initiator to indicate that there is a valid address, data, and command on 
the PVCI. AH of the initiator control, signals are qualified by VAL. The initiator keeps VAL asserted, and 
all of its control signals valid and stable, until it receives the ACK signal from the target. The initiator 
should not assert VAL unless the current transaction is intended for the target. Thus, the initiator may need 
to perform address decoding on its on-chip bus side to generate VAL for the target, thereby accomplishing 
device selection. 



Acknowledge 



Signal Name: 
Signal Abbreviation: 
Polarity: 
Driven By: 
Received By: 
Timing: 



Acknowledge 
ACK 

Asserted Positive 
VCI Target 
VCI Initiator 

Asserted and negated at rising edge of CLOCK. The signal must 
change before Late. 



The ACK signal is asserted by the target to indicate the completion of a transfer between the initiator and 
target. In the case of write operations, this means that the target has accepted the data which is on the write 
data bus or will do so at he end of the current clock cycle. In the case of read operations, the assertion of the 
ACK by the target indicates that the target has placed data to be transferred to the initiator on the read data 
bus. The transaction completes as soon as the rising edge of CLOCK samples ACK. The target may de- 
assert the ACK by the next rising edge of CLOCK unless a new command has been initiated by the 
initiator, or default acknowledge is used. Similarly, the initiator de-asserts VAL by the next rising edge of 
CLOCK unless it is presenting a new command. 



Read /Not Write 



Signal Name: 
Signal Abbreviation: 
Polarity: 
Driven By: 
Received By: 
Timing: 



Read / Not Write 
RD 

Read at positive, write at zero 
VCI Initiator 
VCI Target 

Asserted at rising edge of CLOCK until ACK « 
CLOCK . 



1 at rising edge of 



This signal is a one-bit command asserted by the initiator and indicates the direction of the requested 
transfer. RD indicates that the requested transfer is a read if it is asserted high and a write if it is asserted 
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low. This signal must be valid any time that the VAL signal is assertca. A reaa transicr is a request lor the 
target to supply data on RDATA to be read into the initiator. A write transfer is a request for the target to 
accept data on WDATA from the initiator. 

End-of-Packet 



The EOP signal is de-asserted by the nitiator to indicate that the transfer being performed will be followed 
with a transfer by the initiator to the next higher cell address. This signal is used by the target device to 
preset address in order to improve the data transfer performance. Thus this signal can be interpreted as an 
inverted burst signal. The burst is similar 

to a packet in the Basic VCI, except that rather than prescribing a strict atomicity, it merely indicates a 
contiguous address behavior. The burst transfer is completed once a cell is transferred with the EOP signal 
asserted, or when the Target signals an Abort error. See the definition of ADDRESS signal for the legal 
address behavior during a burst. 

Basic VCI packet with CONT1G signal asserted high and WRAP signal asserted low can be mapped to a 
PVC1 burst. 

3.3.3 Address and Data Signals 



The PVC1 initiator uses ADDRESS to identify which target-resource the current transaction acts upon. The 
N-lines of address bus form a binary number that represents an address. N is a parameter based upon the 
capabilities of the target and is defined and fixed at the time of component instantiation. The most 
significant bit of the address bus will be carried by bitN-1 and the least significant bit of the address will be 
carried by bit 0. ADDRESS[n-l :m] provides a cell address where the cell size is specified by the PVCI's 
total data width; M equals to 0 for cell size 1, 1 for cell size 2, and 2 for cell size 4. Sub-cell addressing is 
handled by the byte enable signals. 

It is permissible to supply the low-order address bits to allow the original full intention of the transfer to be 
maintained. This will rely on knowledge of the endianness of the initiator. This additional information is 
NOT required to complete the operation, which is completely defined by a cell-aligned address and byte 
enables (i.e. the low-order address bits may be tied to logical zero). However, in some systems, some 
efficiency gains may be possible by taking advantage of this information. 

When the EOP signal is low, the ADDRESS of the next cell must be cell_size + ADDRESS of the current 
cell, and the ADDRESS of the current cell must be aligned with the cell boundary. 



Signal Name: 
Signal Abbreviation: 
Polarity: 
Driven By: 
Received By: 
Timing: 



End-of-Packet 
EOP 

Asserted Positive 
VCI Initiator 
VCI Target 

Asserted at rising edge of CLOCK until ACK = 1 at rising edge of 
CLOCK 



Address 



Signal Name: 
Signal Abbreviation: 
Polarity: 
Driven By: 
Received By: 
Timing: ■ 



Address 

ADDRESS[n-l:0] 
N/A 

VCI Initiator 
VCI Target 

Asserted at rising edge of CLOCK until ACK = 1 at rising edge of 
CLOCK 



Byte Enable 
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Signal Name: Byte Enable 

Signal Abbreviation: BE[b-1 :0|0:b« 1 ] 

Polarity: , Asserted Positive 

Driven By: VC1 Initiator 

Received By: VCI Target 

Timing: Asserted at rising 
CLOCK 



of CLOCK until ACK — 1 at rising edge of 



BE is a b-bit field that indicates which bytes of the cell being transferred are enabled. The b equals to total 
data width of the PVCI / 8. These signals must be valid any time that the VAL signal is asserted. The usage 
of byte enables is described in the Peripheral VCI as described in Section 3.4.3 Data Formatting and 
Alignment. 

BE[3:0] is used for little endian VCs where the LSB (Least Significant Byte) is labeled Address 0. 
BE[0:3] is used for big endian VCs where the MSB (Most Significant Byte) is labeled Address 0. 



Write Data 



Signal Name: Write Data 

Signal Abbreviation: WDATA[8b-l : 0] 

Polarity: N/A 

Driven By: VCI Initiator 

Received By: VCI Target 

Timing: Asserted at rising e 
CLOCK 



of CLOCK until ACK = 1 at rising edge of 



The write data lines are driven by the VCI initiator and are used to transfer write data from an initiator to a 
target device. Write data consists of b logical byte lanes, based upon the capabilities of the target and is 
defined and fixed at the time of component instantiation. Allowed vales of b are 8, 16, and 32, allowing 1, 
2 or 4 byte lanes. Bit 8*b-3 is the most significant bit of the most significant byte and bit 0 is the least 
significant bit of the least significant byte. The write data lines must contain valid write data while the VAL 
signal is asserted and the READ is indicating a write transfer. 

For VCs supporting a data size that is not an eight bit increment, the next larger supported bus size will be 
used with the unused bits tied to logic zero. For example, a 1 2-bit device must use a 1 6-bit wide PVCI with 
the 4 Most Significant bits tied to logic zero. 



Read Data 



Signal Name: Read Data 

Signal Abbreviation: RDATA[8b-l : 0] 
Polarity: N/A 
Driven By: VCI Target 

Received By: VCI Initiator 

Timing: Asserted at rising edge of CLOCK until ACK — 1 at rising edge of 

CLOCK 

2 

The read data lines are driven by the VCI initiator) and are used to transfer read data from a target to an 
initiator device. Read data consists of b logical byte lanes, based upon the capabilities of the target and is 
defined and fixed at the time of component instantiation. Allowed vales of b are 8, 16, and 32, allowing 1, 
2 or 4 byte lanes. Bit 8*b-l is the most significant bit of the most significant byte and bit 0 is the least 
significant bit of the least significant byte. The read data lines must contain valid read data while the ACK 
signal is asserted and the RD is indicating a read transfer. 
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For VCs supporting a data size that is not an eight bit increment, the next larger supported bus size will be 
used with the unused bits tied to logic zero. For example, a 12-bit device must use a 16-bit wide PVCI with 
the 4 Most Significant bits tied to logic zero. 



3.3.4 Error Signals 

Response Error 

Signal Name: 
Signal Abbreviation: 
Polarity: 
Driven By: 
Received By: 
Timing: 



Response Error 
RERROR[E:0] 
Positive 
VCI Target 
VCI Initiator 

Asserted at rising edge of CLOCK when ACK = 1 at rising edge of 
CLOCK. 



Error signal is valid only when ACK-1, with the following meaning: 
For ERRLEN = 0 (E=0) 
RERROR=0: Normal (no error) 

RERROR^l : General data error. The entire packet is considered bad. 



For ERRLEN - 1 (E=l) 
RERROR - 00: Normal (no error) 
RERROR = 01 : General data error. 
RERROR - 10: Reserved 
RERROR =11: Abort Disconnect 



The entire packet is considered bad 



For ERRLEN - 2 (E=2) 
RERROR =000: Normal (no error) 
RERROR = xxO: Reserved 

RERROR - 001 : General data error. The entire packet is considered bad 
RERROR = 011: Reserved 
RERROR - 101 : Bad data (retry) 
RERROR 1 1 1 : Abort Disconnect 



After receiving an error, the Initiator may or may not continue with the current packet. If it chooses to end 
the packet prematurely, it can do so by asserting EOP. After this, it can choose not to try a transfer 
anymore (Abort) or Retry part or all of the transfer. For any error, the Target must process the subsequent 
pending cells and packets with the normal protocol, i.e. it must continue sending responses until it has 
processed the EOP with or without further errors signaled. In general, the RERROR is more informative 
than prescriptive, and the Target may not assume any special behavior from the Initiator. The Initiator is 
anyhow encouraged to act responsibly, when it meets an error. 

While sending a non-Abort error, the target should continue with the burst, with or without further errors 
until it receives a cell with EOP. The Initiator can choose to continue with the burst or set the EOP on the 
next cell. In the case of Bad data, just the data of.error may be considered bad. If ERRLEN^ is supported, 
the Target must be capable of accepting a retried request to the same address where it sets Retry-error, but 
the Initiator can choose to retry a cell, burst or nothing at all. It is strongly recommended that all PVCI 
components would support at least one bit error. The PVCI target is strongly recommended to signal an 
error when it receives a request it does not support. 
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3.4 PVCI Protocol 



3.4.1 Operation Types 
Transfer Request 

The following is a list of default transaction types that may be initiated by an initiator across the Peripheral 
Virtual Component Interface (PVCI). An initiator should not initiate an operation of a width that the target 
does not support. 



- Readg: Read one byte. The byte may be on any byte lane expressed with the BE field. Supported 

by all PVCI components 

- Read 16: Read two bytes. The bytes must be on contiguous byte lanes, and are expressed with the 

BE field. The operations must be aligned to 16-bit sub- word boundaries, i.e. transfer with 
BE=01 10 is not allowed. Supported by 2- and 4-byte PVCI components. 

- Read32: Read four bytes. Supported by 4-byte PVCI components. 

- Read N Cells: Read a packet of N cells. The addresses of consecutive cells must be ascending, cell 

aligned, and consecutive. The byte enables of individual cells may have any legal values. 
The last cell is indicated with the EOP signal. Each cell of a packet is individually 
requested and handshaken. Only one pending request for a cell is allowed at a time. 

- Write8: Write-operations are similar to read-operations, except for the data direction 



Writel6 



- Write32 



- Write N Cells 



All transfers are packet transfers of 1 cell or more. A packet transfer of length 1 is indistinguishable from a 
single transfer. Neither the initiator nor the target need support packets that cross address selection 
boundaries. 



The optional Free-BE mode operations are as follows: 



-Read: Read any combination of the bytes in the cell as expressed by BE field. 

-Write: Write any combination of the bytes in the cell as expressed by BE field. 

Transfer Response 



The following is a list of responses that are allowable by a target across the Peripheral Virtual Component 
Interface (PVCI). 



- Not Ready 

- Transfer Acknowledged 

- Error 
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3.4.2 Handshake Protocol 

The two-wire handshake was introduced in the chapter 3.2.2. The Peripheral VCI handshake protocol is a 
subset of the Basic VCI handshake protocol (See 4.2.2). Connecting a Basic VCI target to a Peripheral VCI 
initiator is trivial; the extra signals are tied into constants. The performance achieved is similar to native 
Peripheral connection. It is also possible to connect Basic VCI initiator to a Peripheral VCI target, if the 
initiator knows the limitations of the target. 

The VAL-ACK pair of signals provides a flow control for a cell transferring across the VC Interface, and 
validates all signals associated with that cell. See waveform pictures below for examples. 

• VAL= 1 : Indicates that the initiator is presenting a request. 

• ACK>=1 : Indicates that the target is ready to present the response. 

Rules : 

Rl : not changeable : Once an initiator has asserted VAL, it is not permissible to de-assert it or to change 
any request field, until acknowledged. 

R2 : defaultjack : ACK is permitted to be asserted when VAL is low. 

R3 : valid response : The target must be presenting stable response fields at the rising edge of the clock 
while both ACK and VAL are asserted. 

The initiator must keep VAL asserted, and all of its control signals valid and stable, until it receives the 
ACK signal from the target. The initiator should not assert VAL unless the current transaction is intended 
for the target. 

Packet Transfer 

The packet (burst) transfer is meant for making transfer of block of cells with consecutive addresses more 
efficient. While the EOP signal is de-asserted during a request, the address of next request will be 
ADDRESS+cell_size. The ADDRESS must be aligned to the cell boundary. The packet transfer is 
completed once a cell is transferred with the EOP signal asserted, or when the Target asserts RERROR » 
Abort. In terms of the Basic VCI operations, the Peripheral VCI burst equals to a packet transfer with 
CONTIG signal asserted and WRAP signal de-asserted (See 4.3). The byte enable signals may have any 
legal combination in each cell of the packet. 

Examples: 

The following picture shows waveforms of read and write operations to a target, which needs two clock 
cycles to complete the read, and one cycle to complete the write. If the RERROR signal is not drawn, it is 0 
('"Normal*) for all the examples. 
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Figure 7. PVCI Read and Write 

The following picture shows waveforms of read and write operations to a target, which has default 
acknowledge, i.e. requires single cycle to complete read and write operation. 
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Figure 8. PVCI Read and Write with Default Acknowledge 



The following picture shows how the EOP signal can be used to indicate address predictability to a similar 
target, which has an internal address counter to support pre-fetching read data. Notice that the cell size is 4 
in the example, so the ADDRESS is incremented by 4 at each read. In this example, the target can respond 
to the read in two clock cycles in single transfer, and in one cycle in burst transfer. The ACK signal can be 
generated of the VAL, RD, and EOP signals. 
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Figure 9. PVCI Burst Read 

The following picture illustrates how 'Abort' error response will terminate a burst transfer. 
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Figure 10. Aborting a Burst 



3.4.3 Data Formatting and Alignment 

This section describes the PVCI conventions used for bit / byte ordering and alignment. The Peripheral VCI 
defines bit "0" as the least significant bit of a vectored field such as WDATA, RDATA, or ADDRESS, bit 
"8b-]" as the most significant data bit of each data bus, and bit ,r N-l" as the most significant address bit. N 
is defined to be the number of physical ports or wires associated with a particular instantiation of a PVCI. 

The PVCI is endian independent at the interface. Even though the naming convention may imply a little 
endian interface, the DATA[7:0] means address «■ 0 for little endian, and address — 3 for big endian (in 
case of a 32-bit interface). PVCI component on the other hand must choose an endianness it wants, and 
declare this to the system (unless the component is a memory, where it does not matter). When any 
component interprets a byte address it makes a decision on which byte lane to use. 

The Peripheral VCI will use natural alignment to support peripherals and VC's that handle multiple size 
transfers (e.g. byte as well as word transfers). This means that transfer sizes that are smaller than the 
physical width of the data lines (WDATA or RDATA) will occur in their natural byte lanes and not be right 
or left justified. The byte enable lines (BE) indicate, which byte lane(s) contain the desired data. Table 2 
shows the various data alignments defined for the peripheral VCI data transfers. The entries labeled "xx" 
are don't cares, which provide flexibility and support for byte replication if desired. 
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The PVCI standard has two operational modes related to byte enables: 
Byte Enables in Default Mode 

Every PVCI component must support usage of the byte enable lines that are restricted to the contiguous 
cases. Referring to the following table and the 32-bit example, the allowable patterns for the byte enables 
are 0000, 0001,0010, 0100, 1000,0011, 1100, and 1 1 1 1 . Patterns such as 1011 or 1101 are NOT allowed. 



VCData 
bus size 


Xfer 
size 


BE 

|3:0|0:3] 


Data[31:24] 


Data[23:16J 


Data [15:8] 
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Byte 
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XX 
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Byte 
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Byte 


Byte 
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Table 2: Peripheral VC1 Data Alignment 



Both in big or little endian mode, the BE[0] always corresponds to the byte address 0 in the cell. 
Byte Enables in Free-BE Mode 

The Free-BE mode is an optional operation mode for PVCI components. It is legal in this case to support 
any BE pattern. This mode can be used to make connections to some buses more efficient (e.g. a bus that 
support 3 -byte wide transfers). A Target, which supports the Free-BE mode, automatically supports the 
Default mode. A PVCI Initiator must not require that the Target supports Free-BE mode, but it can take an 
advantage of it, if it does. The operation mode is selected in component instantiation; it is not a run-time 
parameter. 

See VC1 Parameters in the Design Guidelines section of the VC1 Standard. 
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4. Basic VCI 

4.1 Overview 

4.1.1 Scope 

This section defines a Basic Virtual Component Interface (BVCI) to be used in conjunction with on-chip 
system buses, and for point-to-point connections between Virtual Components. The BVCI is a subset of 
Advanced VCI. The BVCI is designed to fulfill most on-chip interfacing needs protocol wise. 

4.1.2 Organization 

This section contains the following chapters: 

• Chapter 4.1 provides an overview for the section 

• Chapter 4.2 gives a technical introduction to Basic VCI 

• Chapter 4.3 provides a detailed description of BVCI signals 

• Chapter 4.4 defines the BVCI protocol in great detail. 

4.2 Technical Introduction to the Basic VCI 
4.2.1 Initiator -Target Connection 

As shown in Figure 1 1 below, the Tequest contents and the response contents are separately transferred 
under control of the protocol, a simple handshake, as introduced in Section 4.2.2. 
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Figure 11. VCI: The Request and Response Each Consist of a Handshake and Contents 
4.2.2 The Handshake 

The BVCI handshake is different from the PVC1 one: The request and response handshakes are completely 
independent of each other. The handshake protocol is aimed at synchronizing two blocks by transferring 
control information in both directions. In the request, the handshake signals are called CMODVAL and 
CMDACK (RSPVAL and RSPACK in the response). Those are acronyms for Command Valid, 
Command Acknowledge, Response Valid, and Response Acknowledge, respectively. 
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Request-contents flow from Initiator to Target; response-contents flow from Target to Initiator. The 
handshake protocol is introduced below. (See Figure 12.) More precise details are provided later in the 
text. This introductory section only serves to provide a basic understanding of the overall process. 
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Figure 12. The Control Handshake for Both Request and Response (Asynchronous ACK) 
In Figure 12: 



• Vertical dashed lines show rising clock edges. 

• VAL shows "at the next rising edge, contents can be read". No actual timing is specified here! 

• ACK, where there is a coinciding VAJL, shows "contents have been read". No actual timing is 
specified here! 

As indicated in the figure (right hand side), maintaining the VAX signal in asserted state for another clock 
cycle after ACK = 1 means that another request or response is ready for reading. VAL and contents must 
be maintained until the next rising clock edge after the ACK has become asserted. 



The ACK can be either generated asynchronously of the VAL as in the Figure 12, or set synchronously at 
the rising edge of the clock as in the Figure 13. (A slow reaction, or late ACK.) If asynchronous ACK is 
used, special design considerations are needed to make sure that the ACK is stable at the rising clock edge. 
For this reason, it is not recommended to use an acknowledge, which is not generated synchronously except 
with "default acknowledge" behavior (See below). 

valid 
contents 
acknowledge 




Figure 13. FulJy Synchronous Control Handshake: ACK Late by 2 Cycles 
4.2.3 The Default Acknowledge 

A "default acknowledge" is permitted on top of the protocol. Since the Acknowledge signal is only 
sampled when VAL = 1, the Acknowledge signal can be asserted (long) before it is needed. Such an early 
ACK has no influence on the protocol behavior. The early ACK is merely "don't care" (the signal is not 
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being considered unless VAL is active at a clock edge). This makes it possible to tie ACK permanently 
active. 

4.2.4 Cells, Packets, and Packet Chains 

4.2.4.1 Cell 

Each handshake is used to transfer a cell across the interface. The cell size is the width of the data passing 
across a VCL It will typically be 1, 2, 4, 8 or 16 bytes. 

4.2.4.2 Packet 

Cell transfers can be combined into packets, which may map onto a burst on a bus. A VCI operation 
consists of a request packet and a response packet. As noted in Section 2, although the responses in a 
packet arrive in the same order as their requests, there is no further relation between the timing of the series 
of requests and the series of responses. The protocol is a split protocol. Packets have been introduced for 
three reasons: 

1. When connecting the BVC1 to a bus: If the underlying bus system is aware that more operations are to 
follow, then no bus arbitration is required between operations of one packet. This may well gain 
valuable bus capacity and speed. 

2. Packets are atomic. That is, the point-to-point connection is maintained over the packet, no matter 
what is in between Initiator and Target - a complex interconnection set-up consisting of one or more 
buses or "nothing at all". This set-up, for example, allows for the monopolizing of a buffer. 

Note, though, that long packets block any other use of the connection system. It is strongly advised to 
keep packets as short as possible to prevent degradation of system performance. 

3. The "Advanced VCI", not yet defined, needs a multi-operation building block for more sophisticated 
packet chains. The packet thus is needed for upward compatibility. 

Packets are similar in concept to "frames" in PCI, where a connection is established to enable data to be 
transferred until the Initiator indicates the termination by closing the frame. 

4.2.4.3 Packet Chain 

Packets can be combined into chains, to allow longer chains of operations to go uninterrupted, as long as no 
higher priority operation claims part of the connection, such as a bus. Packet chains thus produce the same 
bus efficiency that packets provide, without actually excluding any other usage of the connection system. 
The VCI Initiator may merely "notice" that the CMDACK to the first operation of a new packet is 
withheld for a long time. After this pause, the accepting of requests proceeds as if no other usage of the 
connection system had been served. To obtain this behavior, CJVXDVAL should be held asserted between 
the packets of a chain. There is no upper limit to the length of a packet chain. 

4.2.5 Request Contents 

Request contents are partitioned into three signal groups: 

. 1 . Opcode to specify the nature of the request (roughly: read or write), 

2. Packet Length and Chaining to control packets, and 

3 . Address and Data to further detail a read or write action. 

Request contents are validated by the CMDVAL signal. An introductory description of request contents is 
provided below. A more detailed description follows. 
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4.2.5.1 Operation Code (opcode) 

This subset of the request contents is constant for all the operations in a packet. 

• Command: The two bit field U CMD" can specify no-operation, read operation, write operation, or 
read locked. 

• Flags (address algorithm indicators): When none of the flags is asserted, there is no predefined 
relationship among the addresses of subsequent operations in a packet or in a packet chain. Three flags, 
though, can indicate a predefined algorithm among subsequent addresses. This allows Targets to 
compute addresses before they actually arrive via the bus and thus, in some cases, to gain valuable 
clock tics. The address, even when obeying a predefined algorithm, is sent with each operation, 
allowing cost effective targets to function without address prediction. The three flags are: 

1 . Contiguous: Indicates that the addresses within a packet increasing in a contiguous manner. 

2. Wrap (only valid with contiguous addressing): The increase is done modulo the packet length, 
and only when packet length is power of two. This allows for a cache line refill starting with the 
missing word rather than with the word at the lowest address. 

3. Constant (no change in address): This mode is useful for the case when a series of FIFOs have 
contiguous addresses and a packet or a chain is used to empty or fill just one of these FIFOs. 

(In the Advanced VCI, more such flags may be defined.) 

4.2.5.2 Packet Length and Chaining 

This subset of the request contents is constant for all the operations in a packet, apart from the indicator 
"End of Packet", which is only asserted in the last cell of a packet. Contents include: 

• Packet Length: The length of the packet expressed in bytes. 

• End of Packet: This bit is asserted in the last operation of a packet. 

• The bit could be considered redundant in presence of a defined packet length, but it allows a 
Target to be designed without its own explicit remaining length counter. Furthermore, end-of- 
packet is a necessity with an undefined packet length. 

• Chain Length: Presents the amount of packets yet to come in a packet chain. 

• Chain length = 0 thus represents a one-packet chain. There is no need for an "eoc" (end of chain). 

• Chain Fixed: Indicates that the opcode fields (see Section 4.2.5.) and packet length are equal for all 
packets of the chain. Otherwise each packet of a chain has its own such fields and flags. 

4.2.5.3 Address And Data 

This subset of the request contents is issued anew for each cell within a packet. Contents include: 

• Address: The address field designates the Target if several Targets can be reached through the VCI, 
and the detailed location within the target to which the request is made. 

• This standard does not prescribe how Target addresses are allocated to address-space. For 
example, four FIFOs may be assigned consecutive word addresses while memories may occupy 
Megabytes. 

• The address is updated for every operation in a packet even if the address algorithm is specified by 
means of the flags. 
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• The address is specified as the lowest byte address of the concerned data, 

• Byte enable: The main role of byte enable is in write operations. Each asserted bit in this field 
designates a byte in the cell to be actually written into the target. Each non-asserted bit marks a byte 
ar^e not to be overwritten. 

In read operations, byte enable is needed in those wrappers or bridges where cell length or data 
alignment changes. 

There are two separate naming conventions for byte enable, corresponding to a natural endianness. 

• BE[3:0] is used for little endian VCs where the LSB (Least Significant Byte) is labeled Address 0. 

• BE[0:3] is used for big endian VCs where the MSB (Most Significant Byte) is labeled Address 0. 

• Write data: The write data field is only used in write operations. The data lines carry the bytes to be 
copied to the target. 

• Data are "naturally aligned": the byte corresponding with byte address modulo cell size = 0 is at 
byte line 0 on the bus. 

4.2.6 Response Contents 

Each request has its response. The response contents are validated with the RSPVAL signal. Contents 
include: 

• Response Error: The Response Error field indicates whether the request could be handled correctly. 

• Read Data: The data returned as a result of a read request. This field has no meaning in write 
operations. 

• Data are "naturally aligned". The byte corresponding with byte address modulo cell size = 0 is at 
byte line 0 on the bus. 

4.3 Basic VCI Signal Descriptions 

This is the first section of detailed BVC1 technical description. Descriptions of the signals used between the 
Initiator and Target over the VCI are provided in the following. 

4.3.1 Signal Type Definition 



Table 3 specifies the signal types that are used in Section 4.3. They are defined from the point of view of 
the devices rather than the wrapper or arbiter. 



Type 


Description 


IA 


Input to all devices 


IT 


Generated by the Initiator and sampled by the Target 


n 


Generated by the Target and sampled by the Initiator 


MA 


Mandatory signal for both Initiator and Target 


Ml 


Mandatory signal for the Initiator but an optional signal for the Target i 


MC 


Mandatory signal for supporting chaining function for both Initiator and Target 



Table 3: Signal Type Definition 
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Signals that do not have one of the mandatory descriptors listed above are optional and do not support the 
indicated function. 

4.3.2 Signal Parameters . 

Table 4 specifies parameters that are used in Section 4.3. 



Parameter 


Description 


B 


Number of bytes in a cell (must be a power of 2) 


K 


Number of bits in the PLEN field (maximum value is 9) 


N 


Number of bits in the ADDR field 


E 


Number of bits in the RERROR field 


Q 


Number of bits in the CLEN field 



Table 4: Signal Parameters 



4.3.3 Signal Directions 

1 he J igure 14 diagrams the signal directions between the Initiatoi and the Target 



CLOCK 
RESETN 
CMDACK C 
CMDVAL 
ADDRESS 
BE 
CFIXED 
CLEN 
CMD 
CONTIG 
WDATA 
EOP 
CONST 
PLEN 
WRAP 
RSPACK 
RSPVAL 
RDATA 
REOP 
RERROR 



Initiator 



CLOCK 
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CMDACK 
CMDVAL 
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BE 
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CMD 
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WDATA 

EOP 
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PLEN ■>. 

WRAP 
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RDATA 
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Target 

Figure 14. Diagram of VC1 Signal Directions 



4.3.4 Signal List 

All signals included in Table 5 below are assumed to be active-high signals unless explicitly indicated 
otherwise. It is recommended that all signal outputs are stable before Early. It can be assumed that all 
inputs are stable before Late. A detailed signal description follows the summary table. 
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Table 5: Signal List 



Name | Type | Description 








CLOCK 
Clock 


IA 
MA 


CLOCK provides the timing for all transactions. All signals are sampled on the 
rising CLOCK edge. All timing parameters are initiated with respect to this 
edge. 


RESETN 
Reset 


1A 
MA 


Reset is used to bring all devices up on a common signal. RESETN is an active 
low signal and must be asserted for a minimum of 8 CLOCK cycles. The rising 
edge of RESETN is synchronous to the rising edge of CLOCK. 








CIMDACK 

Command 

Acknowledge 


TI 
MI 


Acknowledge is used by the Target to indicate to the Initiator that a given cell 
can be transferred. Hence, a cell is transferred from the Initiator when both 
CMDVAL and CMDACK are asserted. 


CMDVAL 

Command 

Valid 


IT 
Ml 


Valid indicates that the Initiator wishes to perform a cell transfer to the Target. 
The cell is transferred when both the CMDVAL and CMDACK signals are 
asserted. 








ADDRESS[n- 
1:0] 

Address 


IT 
MA 


ADDRESS is the address of the request generated by the Initiator and received 
by the Target. The address updates for every cell transferred within a packet 
and must remain within the address space of a single Target. The pattern of 
addresses that are permissible are defined by the flags (CONTJG, WRAP, and 
CONST signals). ADDRESS contains the lowest byte address for the first 
transfer in the packet. For all cells after the first transfer, ADDRESS is aligned 
to a cell boundary. The combination of a cell-aligned address and byte enables 
is sufficient to perform the transfer correctly. However, the addition of extra 
information in the first address may allow performance advantage in some 
systems. Note that a non cell-aligned address is endian dependent. 


BE 

[b-l:0|0:b-1) 
Byte Enable 


IT 
MA 


Byte Enable indicates which bytes of the cell being transferred or requested by 
the initiator are enabled. 


CFIXED 

Chain Fixed 


IT 

MC 


Chain Fixed indicates that the opcode (CMD, CONTIG, WRAP, and CONST) 
and PLEN fields will be constant across the chain and the address field behavior 
will be the same among packets within a chain. 


CLEN[q-l:0] 
Chain Length 


JT 
MC 


Chain Length indicates the number of packets remaining in a chain. The last 
packet transferred in a chain will have a zero CLEN value. The CLEN value 
can also be tied off to zero if packet chaining is not required. 


CMD[1:0] 
Command 


IT 
MA 


Command is a 2-bit code defining the operation type being attempted by the 
Initiator to the Target and is encoded as follows: 

• 00b = NOP, no data is actually transferred (optional) 

• 01b = READ, data is requested by the Initiator from the Target 

• 1 0b « WRITHE, data is transferred from the Initiator to the Target 

• 1 1 b = LOCKED READ, data is requested by the Initiator from the Target 
with the added function of locking out access to at least the particular cell 
until a WRITE packet is transferred to the same cell (optional) 


CONT1G 

Contiguous 


IT 


CONTIG indicates that the sequence of addresses that will be performed within 
the packet is contiguous. When CONTIG is asserted, the address is normally 
increased by the "cell size in bytes. If a packet does not start or end at a cell 
boundary, the first or last transfers contain less bytes than a cell. In such cases, 
the address is increased not by the length of a cell but by the amount of bytes 
actually transferred in such a first or last cell. 
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Name 


Type 


Description 


WDATA[8b- 

1:0] 

Data 


IT 
MA 


WDATA is the data transferred by the Initiator to the Target during a WRITE 
command. The actual data bits that are enabled during a given cell's transfer are 
defined by the byte enables. The most significant bit is always on the LHS - bit 
8b-l. The least significant bit is always on the RHS - bit 0. 


EOP 

End Of Packet 


IT 
MI 


End Of Packet is asserted on the last cell of a packet indicating that all cells 
associated with the given packet have been transferred. 


CONST 

Constant 


IT 


CONST indicates that the address will remain constant throughout the entire 
packet. When CONST is asserted, CONTIG and WRAP are ignored. 


PLEN[k-l:0] 
Packet Length 


IT 


Packet Length indicates the length of the packet in bytes. The valid range for 
PLEN is 1 to 2*-l (1 to 51 1 given that k is limited to 9). A value of 0 for PLEN 
can be used to indicate that the packet length is undefined (no implied packet 
length). 


WRAP 
Wrap 


IT 


WRAP is used in conjunction with CONTIG to indicate how addresses that 
increment past the boundary indicated by PLEN are handled. If WRAP is 
asserted and PLEN has only a single bit set (indicating a power of 2 packet 
size), the address will wrap around. 






RSPACK 
Response 
Acknowledge 


IT 
MA 


Response Acknowledge is used by the Initiator to indicate to the Target that a 
given cell will be transferred. Hence, a response cell is transferred from the 
target when both RSPVAL and RSPACK are asserted. 


RSPVAL 
Response 
Valid 


TI 
MA 


Response valid indicates that the Target wishes to perform a response cell 
transfer to the Initiator. The response cell is transferred when both the 
RSPVAL and RSPACK signals are asserted. 








RDATA [8b- 
1:0] 

Response Data 


TI 
MA 


Response data is the data that is returned by the Target to the Initiator with 
Read-operations. 


REOP 

Response End 
Of Packet 


TI 
MA 


Response End of Packet is asserted on the last cell of the response packet 
indicating that all cells associated with the given response packet have been 
transferred. 


R ERR OR 

Response Error 


TI 


Response Error is asserted by the Target during a response packet to indicate 
that an error has occurred during the current packet. 



Table 5: Signal List (continued) 



4.3.5 System Level Signals 
Clock 

Signal Name: Clock 

Signal Abbreviation: CLOCK 

Polarity: Active at Positive edge 

Driven By: System 

Received By: VCI Initiator, VCI Target 

This signal provides the timing for the Virtual Component Interface and is an input to both the initiator and 
target that are connected via the BVCL All initiator and target output signals are asserted/de-asserted 
relative to the rising edge of CLOCK and all initiator and target inputs are sampled relative to this edge. 

Reset 

Signal Name: Reset 

Signal Abbreviation: RESETN 

Polarity: Asserted Negative 
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Driven By: System 

Received By: VCI Initiator. VCI Target 

Timing: Asserted > 8 clock cycles 

This signal is used during power-on reset and is used to bring the BVCI to an idle or quiescent state. This 
idle state is defined as the BVCI state in which: 

1. The [CMD|RSP]VAL signals are de-asserted 

2. The [CMD]RSP]ACK signals are de-asserted 

The system must guarantee that RESETN is asserted for at least eight cycles of CLOCK. 
(Larger if parameter RESETLEN is set.) 



4.3.6 Request Signals 
Command Valid 



Signal Name: 
Signal Abbreviation: 
Polarity: 
Driven By: 
Received By: 
Timing: 



CommandValid 
CMDVAL 
Asserted Positive 
VCI Initiator 
VCI Target 

Asserted at rising edge of CLOCK until CMDACK < 
rising edge of CLOCK. 



1 and next 



The CMDVAL signal is driven by a VCI initiator to indicate that there is a valid request cell on the BVCI. 
All of the initiator request signals are qualified by CMDVAL. The initiator keeps CMDVAL asserted, and 
all of its control signals valid and stable, until it receives the CMDACK signal from the target. The 
initiator should not assert CMDVAL unless the current transaction is intended for the target. Thus, the 
initiator may need to perform address decoding on its on-chip bus side to generate CMDVAL for the 
target, thereby accomplishing device selection. 

Command Acknowledge 



Signal Name: 
Signal Abbreviation: 
Polarity: 
Driven By: 
Received By: 
Timing: 



CommandA cknowledge 
CMDACK 
Asserted Positive 
VCI Target 
VCI Initiator 

Asserted and negated at rising edge of CLOCK 



The CMDACK signal is asserted by the target to indicate the completion of a request between the initiator 
and target. In the case of write operations, this means that the target has accepted the data which is on the 
write data bus or will do so at he end of the current clock cycle. In the case of read operations, the assertion 
of the CMDACK by the target indicates that the target has accepted the request and started processing it. 
The request completes as soon as the rising edge of CLOCK samples CMDACK. The target may de-assert 
the CMDACK by the next rising edge of CLOCK unless a new command has been initiated by the 
initiator, or default acknowledge is used. Similarly 3 the initiator de-asserts CMDVAL by the next rising 
edge of CLOCK unless it is presenting a new request. 



Command 



Signal Name: Command 
Signal Abbreviation: CMD 
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Polarity: N/A 
Driven By: VCI Initiator 

Received By: VCI Target 

Timing: Asserted at rising edge of CLOCK until CMDACK = 1 at rising edge 

of CLOCK. 



This signal is a two-bit command-field asserted by the initiator and indicates the nature of the requested 
transfer. It is encoded as follows: 

• 00b = NOP, no data is actually transferred (optional) 

• 0 1 b = READ, data is requested by the Initiator from the Target 

• 1 Ob = WRITE, data is transferred from the Initiator to the Target 

• 1 1 b = LOCKED READ, data is requested by the Initiator from the Target with the added function of 
locking out access to at least the particular cell until a write-operation is performed to the same cell- 
address 

This signal must be valid any time that the CMDVAL signal is asserted. 

End-of-Packet 

Signal Name: End-of-Packet 
Signal Abbreviation: EOP 
Polarity: Asserted Positive 

Driven By: VCI Initiator 

Received By: VCI Target 

Timing: Asserted at rising edge of CLOCK until CMDACK = 1 at rising edge 

of CLOCK. 

The EOP signal is de-asserted by the initiator to indicate that the transfer being performed will be followed 
with a transfer by the initiator to the next higher cell address. This signal is used by the target device to pre- 
calculate address in order to improve the data transfer performance. The packet transfer is completed once a 
cell is transferred with the EOP signal asserted. 

Chain Fixed 

Signal Name: ChainFixed 

S ignal Abbreviation : CFIXED 

Polarity: Asserted Positive 

Driven By: VCI Initiator 

Received By: VCI Target 

Timing: Asserted at rising edge of CLOCK until CMDACK = 1 at rising edge 
of CLOCK. 



Chain Fixed indicates that the opcode (CMD, CONT1G, WRAP, and CONST) and PLEN fields will be 
constant across the chain and the address field behavior will be identical among packets within a chain. 



Chain Length 



Signal Name: 
Signal Abbreviation: 
Polarity: 
Driven By: 
Received By: 
Timing: 



ChainLength 
CLEN 

Asserted Positive 
VCI Initiator 
VCI Target 

Asserted at rising edge of CLOCK until CMDACK = 1 at rising edge 
ofCLOCK. 
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Chain Length indicates the number of packets remaining in a chain. The last packet transferred in a chain 
will have a zero CLEN value. The CLEN value can also be tied off to zero if packet chaining is not 
required. 



Contiguous 



Signal Name: 
Signal Abbreviation: 
Polarity: 
Driven By: 
Received By: 
Timing: 



Contiguous 
CONTIG 
Asserted Positive 
VCI Initiator 
VCI Target 

Asserted at rising edge of CLOCK until CMDACK - 1 at rising edge 
of CLOCK. 



Contiguous-signal indicates that the sequence of addresses that will be accessed within the packet is 
contiguous. When CONTJG is asserted, the address is normally increased by the cell size in bytes. If a 
packet does not start or end at a eel) boundary, the first or last transfer contains less bytes than a cell. In 
such cases, the address is increased not by the length of a cell but by the amount of bytes actually 
transferred in the first or the last cell. In middle-part of the packet, the address always increases by cell size, 
when CONTIG is active. 



Packet Length 

Signal Name: PacketLength 

Signal Abbreviation: PLEN 

Polarity: Asserted Positive 

Driven By: VCI Initiator 

Received By: VCI Target 

Timing: Asserted at rising edge of CLOCK until CMDACK = 1 at rising edge 
of CLOCK. 



Packet Length indicates the length of the packet in bytes. The valid range for PLEN is 1 to 2 k -l (1 to 51 1 
given that k is limited to 9). A value of 0 for PLEN can be used to indicate that the packet length is 
undefined (no implied packet length). In this case, the packet ends as a cell is transferred with EOP active. 
PLEN is held constant over the packet. Thus, PLEN does not indicate "remaining length". 



Constant 



Signal Name: Constant 

Signal Abbreviation: CONST 

Polarity: Asserted Positive 

Driven By: VCI Initiator 

Received By: VCI Target 

Timing: Asserted at rising edge of CLOCK until CMDACK = 1 at rising edge 
of CLOCK. 



Constant indicates that the address will remain constant throughout the entire packet. When CONST is 
asserted, CONTIG and WRAP are ignored. 

Wrap 

Signal Name: Wrap 
Signal Abbreviation: WRAP 
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Polarity: Asserted Positive 

Driven By: VCI Initiator 

Received By: VCI Target 

Timing: Asserted at rising edge of CLOCK until CMDACK 63 1 at rising edge 

of CLOCK. 



Wrap is used in conjunction with CONT1G to indicate how addresses that increment past the boundary 
indicated by PLEN are handled. If WRAP is asserted and PLEN has only a single bit set (indicating a 
power of 2 packet size!), the address will wrap around. If the packet length is not power of two or if 
CONTIG is not active, the WRAP signal is don't-care. The wrap address equals to (ADDR and not 
(PLEN-1)) + PLEN. The next address after wrapping equals to (ADDRESS and not (PLEN-1)). 

Address 



Signal Name: Address 

Signal Abbreviation: ADDRESS[n-l :0] 

Polarity: N/A 

Driven By: VCI Initiator 

Received By: VCI 

TargetTiming: Asserted at rising edge of CLOCK until CMDACK - 1 at rising edge 
of CLOCK. 



ADDRESS is the address of the request generated by the Initiator and received by the Target. The address 
updates for every cell transferred within a packet and must remain within the address space of a single 
Target The pattern of addresses that are permissible are defined by the operation type (CONTIG, WRAP, 
and CONST signals). ADDRESS contains the lowest byte address for the first transfer in the packet. For 
all cells after the first transfer, ADDRESS is aligned to a cell boundary. The combination of a cell-aligned 
address and byte enables is sufficient to perform the transfer correctly. However, the addition of extra 
information in the first address may allow performance advantage in some systems. Note that a non cell- 
aligned address is endian dependent. 

Byte Enable 



Signal Name: Byte Enable 

Signal Abbreviation: BE[b-l :0|0:b-l] 

Polarity: Asserted Positive 

Driven By: VCI Initiator 

Received By: VCI Target 

Timing: Asserted at rising 
of CLOCK. 



of CLOCK until CMDACK = 1 at rising edge 



BE is a b-bit field that indicates which bytes of the cell being transferred are enabled. The b equals to total 
data width of the BVCI / 8. These signals must be valid any time that the CMDVAL signal is asserted. In 
write transfers, the disabled bytes are not overwritten. In read transfers, the target may or may not present 
the disabled bytes in the RDATA bus. They are ignored by the initiator. The direction of the BE-signal 
range numbering depends of the endiannes. 

Write Data 



Signal Name: 
Signal Abbreviation: 
Polarity: 
Driven By: 
Received By: 



Write Data 
WDATA[8b-l :0] 

N/A 

VCI Initiator 
VCI Target 
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Timing: 



Asserted at rising edge of CLOCK until CMDACK = 1 at rising edge 
of CLOCK. 



The write data lines are driven by the VCI initiator and are used to transfer write data from an initiator to a 
target device. Write data consists of b logical byte lanes, based upon the capabilities of the target and is 
defined and fixed at the time of component instantiation. Allowed values of b are power of two. Bit 8*b-l 
is the most significant bit of the most significant byte and bit 0 is the least significant bit of the least 
significant byte. The write data lines must contain valid write data while the CMDVAL signal is asserted 
and the CMD is indicating a write transfer. 

For VCs supporting a data size that is not an eight bit increment, the next larger supported bus size will be 
used with the unused bits tied to logic zero. For example, a 12-bit device must use a 16-bit wide VCI with 
the 4 Most Significant bits tied to logic zero. 

4.3.7 Response Signals 

Response Valid 



Signal Name: 
Signal Abbreviation: 
Polarity: 
Driven By: 
Received By: 
Timing: 



ResponseValid 
RSPVAL 
Asserted Positive 
VCI Target 
VCI Initiator 

Asserted at rising edge of CLOCK until RSPACK = 1 at rising edge of 
CLOCK. 



The RSPVAL signal is driven by a VCI target to indicate that there is a valid response on the BVCI. All of 
the target response signals are qualified by RSPVAL. The target keeps RSPVAL asserted, and all of its 
control signals valid and stable, until it receives the RSPACK signal from the target. 

Response Acknowledge 



Signal Name: 
Signal Abbreviation: 
Polarity: 
Driven By: 
Received By: 
Timing: 



ResponseAcknowledge 
RSPACK 
Asserted Positive 
VCI Initiator 
VCI Target 

Asserted and negated at rising edge of CLOCK 



The RSPACK signal is asserted by the target to indicate the completion of a response transfer between the 
initiator and target. This means that the initiator has accepted the response data, which is on the target's 
response signals, or will do so at he end of the current clock cycle. The response completes as soon as the 
rising edge of CLOCK samples RSPACK. The initiator may de-assert the RSPACK by the next rising 
edge of CLOCK unless a new response has been initiated by the target, or default acknowledge is used. 

Read Data 



Signal Name: 
Signal Abbreviation: 
Polarity: 
Driven By: 
Received By: 
Timing: 



Read Data 

RDATA[8b-l:0] 

"N/A 

VCI Target 
VCI Initiator 

Asserted at rising edge of CLOCK until RSPACK = 1 at rising edge of 
CLOCK. 
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The read data lines are driven by the VCI initiator and are used to transfer read data from a target to an 
initiator device. Read data consists of b logical byte lanes, based upon the capabilities of the target and is 
defined and fixed at the time of component instantiation. Allowed values of b are power of 2 bytes. Bit 
8*b-l is the most significant bit of the most significant byte and bit 0 is the least significant bit of the least 
significant byte. The read data lines must contain valid read data while the RSPVAL signal is asserted and 
the response is to a read request. 

For VCs supporting a data size that is not an eight bit increment, the next larger supported bus size will be 
used with the unused bits tied to logic zero. For example, a 12-bit device must use a 16-bit wideBVCI with 
the 4 Most Significant bits tied to logic zero. 



Response End-of-Packet 

ResponseEndofPacket 
REOP 

Asserted Positive 
VCI Target 
VCI Initiator 

Asserted at rising edge of CLOCK until RSPACK = 1 at rising edge of 
CLOCK. 

Response End of Packet is asserted on the last cell of the response packet indicating that all cells associated 
with the given response packet have been transferred. 



Signal Name: 
Signal Abbreviation: 
Polarity: 
Driven By: 
Received By: 
Timing: 



Response Error 



Signal Name: Response Error 

Signal Abbreviation: RERROR[E:0] 

Polarity: Positive 

Driven By: VCI Target 

Received By: VCI Initiator 

Timing: Asserted at rising edge of CLOCK when RSPVAL - 1 , until RSPACK 
= 1 at rising edge of CLOCK. 



Error signal is valid only when RSPVAL=1, with the following meaning: 
For ERRLEN = 0 (E=0) 
RERROR=0: Normal (no error) 

RERROR- 1 : General data error. The entire packet is considered bad. 

For ERRLEN - 1 (E-l) 
RERROR = 00: Normal (no error) 

RERROR = 01 : General data error. The entire packet is considered bad 
RERROR = 10: Reserved 
RERROR =11: Abort Disconnect 



For ERRLEN -.2 (E=2) 
RERROR =000: Normal (no error) 
RERROR = xxO: Reserved 

RERROR = 001 : General data error. The entire packet is considered bad 
RERROR -011: Reserved 
RERROR = 1 01 : Bad data (retry) 
RERROR -III: Abort Disconnect 
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After receiving an error,, the Initiator may or may not continue with the current packet. If it chooses to end 
the packet prematurely, it can do so by asserting EOP regardless of the PLEN value. After this, it can 
choose not to try a transfer anymore (Abort) or Retry part or all of the transfer. For any error, the Target 
must process the subsequent pending cells and packets with the normal protocol, i.e. it must continue 
sending responses until it has processed the EOP with or without further errors signaled. In general, the 
RERROR is more informative than prescriptive, and the Target may not assume any special behavior from 
the Initiator. The Initiator is anyhow encouraged to act responsibly, when it meets an error. 

It is strongly recommended that all BVCI components would support at least one bit error. The BVCI target 
is strongly recommended to signal an error when it receives a request it does not support. Obviously, VCI 
provides also with a possibility to get error records through normal Read-requests from the Target, but this 
belongs to domain of a particular Virtual Component's implementation. 
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4.4 Basic VCI Protocol 
4.4.1 Protocol Fundamentals 

The Virtual Component Interface (VCI) protocol is described as a set of three stacked layers: transaction 
layer, packet layer and cell layer. 

4.4.1.1 Transaction Layer 

The transaction layer is above the concerns of hardware implementation. It defines the system as a series of 
communicating objects which can be either hardware or software modules. The. information exchanged 
between Initiator and Target nodes is in the form of a request-response pair as illustrated in Figure 15 
below. 




Figure 15. System Transaction Layer View of Information Transfer over the VCI 
Transaction 

A pair of request and response transfers is called a transaction. Typically, the basic unit of information 
exchanged is some form of data structure. As the communication is decomposed to lower layers of 
abstractions, the basic transfer unit becomes smaller. 

4.4.1 .2 Packet Layer 

The packet layer adds generic hardware constraints to the system model. In this layer, VCI is a bus- 
independent interface that supports point to point physically address-mapped split transactions between 
Initiators and Targets in unit time. There will not yet be a commitment to a particular interface width. In 
this layer, the request and response information to be transferred across the interface is split into more 
manageable chunks, on the basis of generic hardware constraints. This is illustrated in Figure 16 below. 




Figure 16. Packet Layer View of Information Transfer over the VCI 

Operation 

A transaction is called a VCI operation if the information is exchanged using atomic request and response 
transfers across the interface. The information exchanged during an operation is in the form of a VCI 
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packet, a packet layer transfer unit defined in the following section. In a packet layer, a VCI transaction 
decomposes into one or more operations. 

Packet 

Packet is the basic unit of information that can be exchanged over the VCI in an atomic manner. The point 
to point connection between Initiator and Target is maintained throughout the transfer of a packet. 

The request and response transfer units of a VCI transaction are decomposed into one or more request- 
response packet pairs. Multiple packets can be combined to form larger, non-atomic transfer units called 
packet chains, as explained in the next chapter. A VCI operation is a single request-response packet pair. 
For each request packet transferred from Initiator to Target, there will be one corresponding response 
packet transferred from Target to Initiator. The Targets shall return response packets in the same order as 
request packets are issued. 

The content of a packet depends on whether it is a request or response packet and the type of operation 
being carried out - such as read, write etc. The data field of request packets is relevant only for write 
operations. The field, RDATA, in response packets contains valid values only for read and locked_rcad 
operations. The request packet header contains information on packet chaining. More details on other 
packet fields will be introduced in subsequent sections. 

Packet length is the number of bytes transferred during a read, write, or locked_read operation. This field is 
irrelevant for NOP operations. A zero value specified for PLiEN in read, write, or locked_read operations 
indicates that the length of the packet is undefined. Long packets can result in reduced arbitration overhead 
and some optimization in certain areas like read pre-fetching and SDRAM access. This can improve the 
data transfer rate for that particular thread. However, very long packets transferred over a shared 
interconnect system lock out all other agents, causing degradation of the system performance. Hence, it is 
highly recommended to use short packets to optimize the overall system performance and to use the packet 
chaining mechanism, described in the next section, to create long, but non-atomic, transfers. 

Packet Chain 

The packet chain mechanism allows a VCI Initiator to describe linkage between related packets to the 
system. The system can combine chained packets into larger, more efficient, higher performance transfers 
that satisfy the constraints of the system application. Packet chains produce the same transfer efficiency 
that long packets provide without requiring the entire transfer to be atomic. 

Two fields in the request packet header, CJLEN and CFIXED, specify the packet chaining information. 
CLEN describes the number of packets remaining in the chain (not including the current packet). This field 
is normally decremented with every transmitted packet. 

The flag, CFIXED, provides information about the linkage between the header fields among the packets in 
a packet chain. If set, CFIXED guarantees that the opcode and packet length fields will be constant across 
the chain. 

The packet chain mechanism allows the VCI Initiators to minimize their packet length to that which is 
required for proper operation (i.e. functionality). This mechanism concurrently provides the interconnect 
logic and the Target with enough information for optimizing the chained transfers to meet application 
performance and efficiency requirements. 

4.4.1,3 Cell Layer 

The cell layer adds more hardware details such as interface width, handshake scheme, wiring constraints, 
and a clock to the system model. This layer is not concerned about shared interconnects and arbitration for 
such services. In the cell layer, VCI is viewed as a bus-independent, point to point interface that supports 
physically address-mapped split transactions between Initiators and Targets, using a cycle-based handshake 
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protocol. Introduction of interface width information enables decomposing of packets (the basic transfer 
unit defined in the packet layer) into cells that are handshaken under a cycle-based protocol across the 
definitive sized interface. 

Cell 

A cell is the basic unit of information, transferred on rising CLOCK edges under the VAL-ACK 
handshake protocol, defined by the cell layer. Multiple cells constitute a packet. Both request and response 
packets are transferred as series of cells on the VCI. The number of cells in a packet depends on the packet 
length and the interface width. 

The structure of a cell is very similar to that of a packet, except for the decomposing of WD ATA and byte 
enable fields and the introduction of end-of-packet fields. The opcode fields, chaining information, and 
PLEN in a request cell are the same as the corresponding request packet fields. 



The request cell structure and response cell structure is detailed in Tables 6 and 7 below. 













Packet chain 
Information 


CLEN | Number of remaining packets in the chain 








ADDR 


Address of each cell being transferred 






Opcode 




CMD 


Command: read, write, nop or locked read 










WRAP 


WRAP address mode 






wmmmmmMMM, msmms i m 




BE 


Byte Enable: indicates which bytes are involved in the operation 








mmm mmmm. wmmMm 


[ j EOP | Indicates if the cell is the last one in the request packet 


Table 6: Request Cell Structure 












RERROR 


Error status for the cell 










REOP 


Indicates if the cell is the last one in the response packet 



Table 7: Response Cell Structure 

VAL-ACK Handshake 

The VAL-ACK handshake provides unambiguous synchronization of Initiator and Target modules for 
transferring cells over the interface. It is a simple handshake protocol based on two control signals. Two 
separate sets of handshake signals are used in the VCI interface: one for transferring request cells from 
Initiator to Target, and the other for transferring response cells from Target to Initiator. The transfer of 
request and response cells over the interface are completely de-coupled, concurrent events. The handshake 
fundamentals explained below apply to both request and response channels. Generic names, VAL and 
ACK, are used in the discussion for the control signals. These names represent CMDVAL and CMDACK 
signals of the request channel and RSPVAL and RSPACK signals of the response channel. 



Cell transfer on the channel is solely controlled by the following two signals (Table 8): 



VAL 


Driven by the initiator module to indicate that a cell was placed on the interface and is ready for 
transfer 


ACK 


Driven by the target module to indicate that it has received the cell, if any was present as 
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Tabic 8: Handshake Signals 
Table 9 summarizes different encoding for the VAL-ACK signals and the corresponding channel states. 











0 


1 o 1 


IDLE 1 


The channel is in idle state. | 










o 


j i T 


DEFAULT_ACK | 


Ready to Grant ] 




Km 







Table 9: VAL-ACK Encoding and Channel States 



The channel is in IDLE state when both VAL and ACK are de-asserted. The initiator module 
unconditionally asserts VAL when the cell information is placed on the interface. The target module may 
delay the assertion of ACK if it is not ready to accept the cell. The channel is said to be in REQUEST state 
if ACK is not asserted for a VAL on the rising edge of the CLOCK. The channel state transitions to SYNC 
when both VAL and ACK are asserted. The handshake synchronization and cell transfer occur on each 
CLOCK edge when the VCI is in SYNC state. (See Figure 17.) 



clock 
val 
cell 




t y 












/ 


A 


/ 








ram: 










ack 












■ 






/ 















Figure 17. VAL-ACK Handshake for Single-Cell Transfer 

While transferring a multi-cell packet, either module can insert wait cycles by de-asserting VAL or ACK. 
The receiving module can assert ACK even when VAL is not present, to indicate that it is ready to ACK 
the next VAL. The corresponding channel state is DEFAULT_ACK. In this case, cell transfer will occur on 
the first CLOCK edge on which VAL is asserted. 

Once the initiator module asserts VAL, it cannot change that signal until the requested cell is transferred, 
regardless of the state of ACK. Similarly, once the receiving module asserts ACK, it should not de-assert 
that signal until a cell is transferred. Generally, neither module shall change its mind once it has committed 
to the cell transfer. 

However, de-committing of the ACK signal may be necessary in certain scenarios, such as a default ACK 
from a bus wrapper module to an Initiator, where this bus is "parked". Such deviations from the 
recommended interface behavior should be clearly documented when VCs are implemented. Table 10 
below summarizes all the permitted state transitions. 













IDLE 


IDLE 1 


Valid 


Continues in idle 










IDLE 


DEFAULT_ACK [ 


Valid 


Default Acknowledge asserted 
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msmmmmmm 






VAL 


IDLE 


Invalid 


Valid de-committing not allowed 


■HBHeHHBMHHI 








VAL 


DEFAULT ACK 


Invalid 


Valid dercommitting not allowed 




mmmsammm 






DEFAULT ACK 


IDLE 


Invalid 


Acknowledge de-committing not allowed 






mmmmi 




DEFAULT ACK 


DEFAULT GRANT 


Valid 


Acknowledge maintained 










~ SYNC 


IDLE 


Valid 


Back to idle 




mmwm 




SYNC 


DEFAULTACK 


Valid 


Default Acknowledge asserted 






mmmm 





Table 10: Permitted State Transitions 



VAL Time and ACK Time 

VAL_time and ACK_time are introduced as a way of classifying the handshakes. Definitions follow: 

• VAL_time = number of cycles where VAL is de-asserted between cell transfers. 

• ACK_time = number of cycles where VAL is asserted before ACK is asserted. 
Figures 17-19 illustrate different VAL-ACK handshakes. 



clock 
vat 
cell 


gP 


\ 1 






/ 

(DEEE 




ack 








Hi 




i / 


1 ! 1 \ 





Figure 18. VAL- ACK Handshake with VAL Time = 0, ACK Time - 0 




Figure 19. VAL-ACK Handshake with VAL Time - 0, ACK Time - 1 
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Figure 20. VAL-ACK Handshake with VAJL Time = 1, ACK Time - J 
4.4.2 Basic VCI Operations 

The basic transfer mechanism in VCI is packet transfer. Every operation on the VCI consists of a request 
packet transfer from the Initiator to the Target and a response packet in return. Both Initiator and Target 
modules are responsible for transferring the VCI request and response packets across the interface in an 
atomic manner. A packet is sent as a series of cells with the EOP (end of packet) field in the last cell set to 
value 1. Each cell is individually handshaken across the interface under the VAL-ACK handshake. Either 
the Initiator or the Target can insert wait cycles between cell transfers by de-asserting VAL or ACK. The 
order of packets and the number and order of cells within packets should be maintained the same between 
request and response transfers. 

The transfer of request and response cells over the interface are completely de-coupled concurrent events. 
The signals used for encoding cell information, handshake signals, and the timing of the request and 
response transfers are totally, separate. 

All VCI signals are sampled on the rising edge of the CLOCK. The handshake signals CMDVAL, 
CMDACK, RSPVAL, and RSPACK are sampled on every rising CLOCK edge. The rest of those signals 
that encode the request and response cells are sampled on rising CLOCK edges, qualified by the 
corresponding VAL signal. The timing diagrams in this section show the relationship of relevant signals 
involved in illustrated operations. 

4.4.2.1 Read Operation 

Figure 21 below illustrates a 32-byte read operation on a 32-bit wide VCL The operation starts with the 
Initiator placing the first cell of a request packet on the interface and asserting CMDVAL on CLOCK 2. 
The cell information is encoded in the signals: CMD, CONTIG, WRAP, CONST, PLEN, EOP, 
ADDRESS, and BE. The fields on chaining information, CLEN and CFIXED, are both set to value 0 for 
this operation and are not shown in the diagram. 

As shown in Figure 21 : 

• The CMD and addressing mode flags, CONTIG, WRAP, and CONST, specify that the packet is part 
of a read operation with contiguous cell addresses. 

• The field PLEN indicates that the packet length is 32 bytes. 

• The address field contains the address of the Target and the byte address of the location from where the 
data is requested. 

• BE indicates which byte lanes are involved in the first cell transfer. 

• EOP is set to 0 to indicate that the current cell is not the last one in the packet. 



Copyright VSI Alliance 1999 



APPENDIX B Page 42 



WO 02/05144 



61 



PCT/US01/01820 



The earliest the cell transfer can complete is in CLOCK period 2 itself, if the signal CMDACK is asserted 
combinatorially or if the channel is in default acknowledge state. In this example, the target module asserts 
CMDACK in the CLOCK period 3 (ACK time « 1) and the cell transfer completes in that CLOCK cycle. 

The Initiator module updates the ADDR and BE signals to reflect the address and byte enable information 
for the second cell of the packet being transferred. Note that the address(n-l :m) field does not change. (It is 
illegal to address more than one Target within same packet.) The signals: CMD, CONTIG, WRAP, 
CONST, and PLEN (also CLEN and CFIXED, which are not shown) are common to all the cells in the 
request packet. ■ 

clock 
cmdvat 
cmdack 



conUg 
wrap 
constant 
ptan(teO) 

eop 
addrese(rv1 :m) 
Bddress(m-1:0) 

be 
rspvaj 
rspack 
reop 
rerror 
rdata 



Figure 21. 32-byteRead Operation on a 32-bit VC1 

All the eight cells in the request packet are transferred in 8 CLOCK cycles with CMDVAL and 
CMDACK asserted corresponding to VAL time = 0 and ACK time = 0. The CMDVAL for the last cell is 
asserted at CLOCK period 9 and the cell transfer completes on the same cycle. Note that the Initiator 
asserted the signal EOP at CLOCK 9 to indicate that the cell being transferred is the last one in the packet. 

In the response channel, the Initiator continuously asserts the signal, RSPACK, indicating its readiness to 
accept the response cell with ACK time = 0. This is a default acknowledge condition, as the CMDACK is 
asserted when CMDVAL is not present. All the eight response cells are transferred in 8 CLOCKs as both 
VAL time and ACK time are 0. The first cell is transferred in CLOCK 3 when the Target module asserts 
RSPVAL. The Target continues to assert RSPVAL until CLOCK 10, transferring one cell on every 
CLOCK edge. At CLOCK 10, the Target also indicates to the Initiator through REOP that the current cell 
is the last one in the response packet Each response cell contains the read data (on RDATA) and the error 
flag (on RERROR). 

4.4.2.2 Write Operation 

Figure 22 illustrates a 32-byte write operation on a 32-bit VCI. A write operation is similar to a read 
operation except that: 
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1 . The Initiator provides the write data on signal WDATA as part of each request cell, and 

2. The field RDATA is not significant. 

The operation starts with the Initiator placing the first cell of a request packet on the interface and asserting 
CMDVAL on CLOCK 2. The cell information is encoded in the signals: CMD, CONTIG, WRAP, 
CONST, PLEN, EOP, ADDRESS, BE, and WDATA. 

As shown in Figure 22 below: 

• The signal, CMD, indicates that the packet is part of a write operation. 

• The addressing mode flags, CONTIG, WRAP, and CONST, specify that the cell addresses are 
contiguous. 

• BE indicates which byte lanes arc valid in the write data. 

The Initiator module updates the ADDRESS, BE, and WDATA signals upon every cell transfer to reflect 
the byte address, enable information, and the data, until all the four cells in the packet are transferred. Note 
that the address is updated for every cell, even though the opcode field indicates that the cell addresses are 
contiguous. 

dock 
cmdval 
cmdack 

cmd 
contlg 

constant 
plonflcO) 

oop 

oddre3n(r>1 :m) 

address (ra-1:0) 

data 
bo 
rapvol 
repack 
reap 
rerror 

Figure 22. 32-byte Write Operation on a 32-blt VC1 

All the eight cells in the request packet are transferred in 8 CLOCK cycles with CMDVAL and 
CMDACK asserted corresponding to VAL time = 0 and ACK time = 0. The response cells are also 
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transferred in 8 CLOCKs. The only information contained in write response cells is the error flag (on 
RERROR). 

4.4.2.3 Other Operations 

Two other operation types supported on VC1 are MOP and Locked Read. The NOP operation is similar to a 
read or write operation, except that the CMD field of the request packet contains value '00' (NOP) and 
there is no data transferred along with request and response cells. 

The locked read operation is similar to a read operation. The only difference is in the CMD signal 
encoding. The Target module/system locks out at least the memory locations addressed by the locked read 
request until another operation is issued to the same locations by the same Initiator. 

Packet Chain Transfer 

Figure 23 below illustrates a read transaction on the VC1 composed of two operations grouped through the 
packet chaining mechanism. The operations are similar to the normal read operations except that the packet 
chaining information is provided along with the request packets. This information is encoded on signals 
CLEN and CFIXEP. 

CLEN specifies the number of packets remaining in the chain excluding the current one. In this example it 
is 2-1 = 1. Note that this information is CONST within the packet and dynamic across packets. CLEN is 
specified as 0 for the second request packet, indicating that it is the last packet in the chain. 

The flag, CFIXED, is asserted for the first packet to indicate that same opcode will be used for all the 
packets in the chain. CFIXED also guarantees that the address relationship between the last cell of a packet 
in the chain and the first cell of the following packet will be the same as the one defined by the ADDRESS 
mode flags for cells within packets. In this example, CFIXED = 1, guarantees that the cell addresses will 
be contiguous across the packet chain. 
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Figure 23. Packet Chain Transfer on the VCI 



The chaining information on the first packet along with the packet header information conveys to the 
Target module that the Initiator module intends to read (CLEN + 1) x PLEN = (1 + 1) x 16 = 32 bytes of 
data from contiguous address locations starting from ADDR1. This information provides an option to the 
Target module to combine the two request packets to improve the transfer efficiency, if possible. In this 
example, it is assumed that the Target treats the packet chain as a single packet containing 8 cells to 
perform a high efficiency data fetch. Note that the first response packet has a latency of 9 CLOCKs 
whereas the second response packet arrives 4 CLOCKs after the arrival of the corresponding request 
packet. 

4.4.2.4 Address Modes 

The VCI requires the Initiator to provide cell addresses along with every Tequest cell transferred to the 
Target module. In addition, the Initiator may also specify a predefined algorithm to calculate subsequent 
cell addresses from the previous cell address using the three addressing mode flags, CONTJG, WRAP, 
and CONST. When none of the flags are asserted by the Initiator, it indicates that there is no predefined 
relationship among cell addresses. 



Random Address Mode 



When none of the opcode flags are asserted, the initiator specifies random cell addressing mode. In this 
case, there are no predetermined relationships among cell addresses. Figure 24 below illustrates a 16-byte 
read operation with random address mode. 




Figure 24. 16-byte Read Operation with Random Address Mode 



Contiguous Address Mode 
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When CONTIG is asserted and WRAP is not asserted, the cell addresses advance in a contiguous manner. 
In this case, cell addresses can be calculated by adding the number of bytes transferred in the previous cell 
to the previous cell address. Figure 25 below illustrates a 12-byte read operation with contiguous address 
mode. 




Figure 25. 12-byte Read Operation with Contiguous Address Mode 



Wrap Address Mode 

This addressing mode is specified by assertion of the flags, CONTIG, and WRAP. If the WRAP mode is 
specified and the field PLEN is specified as 2 A A, then the following action take place. The cell address 
advances in a contiguous manner and wraps around when the sum of the number of bytes transferred and 
the lower A+l bits of the cell address is more than the value of PUEN. (The carry bit does not propagate 
beyond bit location A.) A 16-byte read operation in WRAP address mode is illustrated below in Figure 26. 
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Figure 26. 16-byte Read Operation with Wrap Address Mode 
Constant Address Mode 

The constant address mode is specified using the flag CONST. When this mode is specified for a request 
packet, the cell address remains the same as the starting cell address across all the cells in the packet/packet 
chain. Figure 27 below illustrates a 16-byte read operation in constant mode. Note that all the bits in the 
ADDRESS(n-l .0) remain constant for all the cells in the packet. 




Figure 27. 16-byte Read Operation with Constant Address Mode 
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4.4.3 Basic VCI Signaling Rules 

The following rules apply: 

• For each packet transferred on the request channel, there should be exactly one response packet 
transferred back on the response channel. 

• The order in which packets are transferred on the response channel should be same as the order in 
which the corresponding packets appear on the request channel. 

• The number of cells in response packets should be same as in the corresponding request packets 
irrespective of the opcode. 

• The order of cells within a response packet should be same as the order in the corresponding request 
packet. 

• Once CMDVAL is asserted, the initiator module cannot change that signal until the requested cell is 
transferred regardless of the state of CMDACK. 

• Once a cell is placed on the interface and CMDVAL is asserted, the initiator module cannot modify 
the cell content until the requested cell transfer is complete. 

• ADDRESS(n-1 :m), the top n-m bits of the ADDRESS signal which indicates the target being 
addressed, should remain constant across all the cells in a packet. 

• Opcode signals, CMD(1 :0) and the ADDRESS mode flags should remain constant throughout the 
packet transfer. 

• PLEN signal, which indicates the length of the request packet, should remain constant throughout the 
packet transfer. 

• CLEN and CFIXED signals should remain constant across all the cells within a packet. It is 
recommended that the field, CLEN, should either stay constant or decrement (by one) with every 
packet transfer. It is legal for the initiator to change CLEN in unexpected ways between packets. This 
behavior is discouraged, as it adds complexity to the Target. Initiators that exhibit this discouraged 
behavior must document it, and Targets must document what CLEN behavior they can accept. 

• Changing the CIYED field between packets in a packet chain is strongly discouraged. Initiators that 
exhibit this discouraged behavior must document it. 

• Asserting the flag WRAP without asserting CONTIG is invalid. Asserting WRAP when PLEN is not 
a power of 2 value is also invalid. 

• The Initiator shall not assert byte enable bits for those bytes that are outside the address range indicated 
by the address and PLEN fields. 

• )t is recommended that once the receiving module asserts CMDACK, the module cannot change that 
signal until the next clock cycle. This insures the transferred cell is not corrupted.. 
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4.4.4 Additional Timing Diagrams 

Additional timing diagrams follow. 

clock 
cmdval 
cmdack 
cmd 

plen(k:0) 

j 

eop 

address(n-1 :m) 
address(m-1:0)j 
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rerror 

Figure 28. 1-byte Write Operation on a 32-bit VC1 




Figure 29. 4-byte Write Operation on a 32-bit VCI 
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5. Design Guidelines 
5.1 User 1 Guide 

This section describes the high-level responsibilities of the VC Initiator and VC Target, together with the 
associated implementation considerations, discussing also about the differences between Basic VC1 and 
Peripheral VCI. The focus is especially in describing use of the VCI with an on-chip bus. 

While the VC Initiator to OCB Initiator Wrapper interface is identical in protocol to the OCB Target 
Wrapper to VC Target interface, the differences between the VC and the OCB show up in the 
implementation considerations. There are at least two good reasons to keep the VC->OCB interface 
identical to the OCB->VC interface: 




Figure 30. VCI Block Diagram 

1 . This facilitates direct VC=>VC connections (i.e. without an intervening OCB) 

2. VC Initiators have communication features similar to OCBs (pretty obvious, given the heritage of most 
OCBs). Thus, we can use existing VC Initiators as reasonable test cases to ensure that the OCB 
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Initiator responsibilities are reasonable. A similar argument may be made for the OCB Target 
responsibilities. 

The intended use for the Peripheral VCI is in VC-VC communication, and wrapping a VCI Target to an 
On-Chip Bus. Although it is possible to use the Peripheral VCI as a bus initiator, this is an unlikely case, 
since usually the peripheral bus initiator is a bus bridge from a system bus. So, the Peripheral VCI 
properties are tuned more towards the use as a peripheral bus target. The Basic VCI is more versatile and 
its features are tuned towards use as either an initiator or a target for an OCB. 

Another possible topology is presented in Figure 3 1 . In this case, there is no bus, but all the VCI Targets 
are connected point-to-point to a central OCB- VCI bridge. In this case, the bridge looks like a single target 
to the OCB in question, and contains a number of VCI Initiators. The bridge is more complicated than a bus 
wrapper, but the electrical design of point-to-point VCI connections may be easier than design of a shared 
bus. 




Figure 31. VCI with Star Topology 



The following discussion covers the responsibilities of four different entities, as depicted in Figure 30: VC 
Initiator, OCB Initiator Wrapper, OCB Target Wrapper, and VC Target. Main differences with the BVC1 
and the PVCI are discussed. 

5.1.1 VC Initiator Responsibilities 

The VC Initiator is in complete control over the presentation of requests on its VC Interface; there is no 
arbitration. It asserts the CMDVAL (VAL for PVCI) signal to indicate that a valid request information are 
present. The size of ADDRESS and [W|R]DATA are dictated by the VC's capabilities, as is the set of 
supported transfer widths. It must hold the request information stable until it samples CMDACK (ACK for 
PVCI) asserted at the rising edge of CLOCK. On a read transfer, PVCI Initiator must acquire RDATA once 
it samples ACK asserted at the rising edge of CLOCK in PVCI. In BVCI, the VC Initiator can delay 
acquiring RDATA by holding RSPACK de-asserted, while RSPVAL is asserted. Once the BVCI Initiator 
asserts the RSPACK, it must complete the response transfer once it samples RSPVAL asserted at the rising 
edge of CLOCK. 
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TAe provider of the VC Initiator must provide a list of VCI conliguration parameters for the VC, including 
such aspects as address/data bus widths, supported transfer widths, and timing data. These parameters allow 
the system integrator to configure the OCB Initiator Wrapper to meet the constraints of both the system and 
the VC Initiator. 

5.1.2 OCB Initiator Wrapper Responsibilities 

The OCB Initiator Wrapper is responsible for accepting the request from the VC Initiator, and controlling 
the OCB (as an OCB Initiator) to accomplish the transfer. In particular, the OCB Initiator Wrapper is 
responsible of making request to and accepting responses from the bus arbiter, initiating the transfer on the 
OCB (inserting any required OCB tum-around cycles), handling any OCB-level handshaking and getting 
Read data from the OCB. In most instances, the OCB Initiator Wrapper should not need to store any 
request information (particularly address or write data) on behalf of the VC Initiator, since the OCB 
Initiator Wrapper CMDACK (ACK) signal can be used to force the VC Initiator to hold the request 
information. It may need to store response information (such as RDATA) in the BVCI, if the VC Initiator 
expresses that it cannot accept the read data by not asserting the RSPACK. 

However, electrical concerns will typically force the OCB Initiator Wrapper to buffer the request signals to 
drive long OCB wires, as well as dealing with OGB topology issues (tri-state vs. multiplexed buses, for 
instance). The OCB Initiator Wrapper is responsible for ensuring that the OCB timing is correct, and that 
VCI RDATA and handshaking signals make the required setup time to the VC Initiator. 

The OCB Initiator Wrapper should be configurable enough to adapt to a range of possible VC Initiator 
capabilities. In particular, the OCB Initiator Wrapper should have variable address and data bus widths, and 
support for multiple transfer widths. This configurability allows the system integrator to match the OCB 
Initiator Wrapper to the VC Initiator. 

Several issues arise with respect to the configuration of the OCB Initiator Wrapper. A VC Initiator with a 
16-bit ADDRESS may need to connect to an OCB with a 32-bit address. In such a case, the system 
integrator should be free to synthesize the most significant 16 bits of the OCB address by whatever means 
are appropriate for the system. One way might be to statically configure the upper bits into the OCB 
Initiator Wrapper. Another method might involve placing a writable register somewhere on the OCB to 
hold the upper bits. The OCB Initiator Wrapper is also responsible for any required data shifting. Data 
shifting which can arise from endianness differences between the VC Initiator and the OCB, or width 
mismatches should not be required, in general. This requirement can generally be lifted by the appropriate 
connection of the VC byte lanes to the VCI byte lanes, if the endianness is of static nature. 

5.1.3 OCB Target Wrapper Responsibilities 

The OCB Target Wrapper is in complete control over the presentation of requests on its VCI; there is no 
arbitration. The OCB Target Wrapper acts as an OCB Target; it must convert the OCB transfer into a VC1- 
compliant transfer. In particular, it must translate OCB request information into the VCI CMDVAL (VAL) 
signal, which indicates the presence of a valid VCI request that is intended for the VC Target. Device 
selection mechanics are very specific to different OCBs. Traditional approaches to device selection include 
distributed address decoding and centralized address decoding. For a distributed-decoding OCB, the 
address decoder to determine VCI CMDVAL (VAL) will likely live inside the OCB Target Wrapper. For a 
centralized-decoding OCB, the VCI CMDVAL (VAL) signal is likely just a buffered version of the select 
signal from the centralized decoder. 

The OCB Target Wrapper presents the request information across the VCI to the VC Target. It must hold 
the request information stable until it samples the VCI CMDACK (ACK) asserted. Since the OCB Target 
Wrapper is responsible for ensuring compliance with the OCB transfer protocol, most OCB Target 
Wrappers will use OCB Target handshaking to force the OCB Target Wrapper to hold the request 
information stable (i.e. insert wait states). Thus, data and address storage is rarely required in the OCB 
Target Wrapper. The OCB Target Wrapper may need to delay the assertion of CMDVAL so that it and the 
other request fields satisfy the VC Target setup time. It should wait until the VC Target returns CMDACK 
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before releasing the OCB resources associated with the transfer. It is the OCB Target Wrapper's 
responsibility to ensure that VCI RDATA makes the timing path back across the OCB to the OCB Target 
Wrapper. Since the two-wire Peripheral VC1 handshake does not allow the OCB Target Wrapper to force 
the VC Target to hold RDATA, the OCB must run slow enough to allow RDATA to make it back across 
the OCB or else data storage is required inside the OCB Initiator to acquire RDATA. The Basic VC1 
handshake allows for the OCB Target Wrapper to stall the VC Target. In any case, it is typically the OCB 
Target Wrapper's responsibility to buffer RDATA to drive the OCB data wires, thereby isolating the VC 
Target from the loading and topology (tri-state, multiplexed, etc.) of the OCB. 

The OCB Target Wrapper should be configurable enough to match its VCI address and data bus widths, 
and transfer widths to the VC Target's implementation of the VCI. This configurability is key to allow the 
system integrator to design working systems using the VCI. When the OCB has a different data bus width 
than the VC Target, it is the OCB Target Wrapper's responsibility to accomplish any required data 
multiplexing. The VC Target ADDRESS is typically much narrower than the OCB ADDRESS; the VC 
Target should be configurable so that only the required ADDRESS bits are presented to the VC Target. 

5.1.4 VC Target Responsibilities 

The VC Target is responsible for accepting the request from the OCB Target Wrapper and accomplishing 
the transfer. Since every request presented to the VC Target is intended for it, the VC Target should be 
designed to acknowledge every transfer. In simpler terms, the ACK response will often be a delayed 
version of the VAL. The VC Target should typically delay assertion of ACK until it has completed the 
transfer of the request; this forces the OCB Target Wrapper to hold the request information steady, thus 
eliminating the need for the VC Target to store the request. 

The provider of the VC Target must provide a list of VCI configuration parameters for the VC, including 
such aspects as address/data bus widths, supported transfer widths, and timing data. These parameters allow 
the system integrator to configure the OCB Target Wrapper to meet the constraints of both the system and 
the VC Target. 

5.1.5 VCI to VCI Conversions 

VCI components with different parameters, as size, are not supposed to be connected together directly. A 
special wrapper has to be used in this case (See Figure 32). The wrapper is a VC, which takes care of 
buffering, and other logic needed to map different VCIs together. This situation happens, when using VCI 
for point-to-point communication. When connecting different VCIs through an OCB, the OCB wrappers 
take care of size conversions. 




Figure 32. Interconnecting Different-Size VCI Components 
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5.2 VCI Parameters 

These parameters control: 

• Generation of the VC itself for a soft VC. 

• Configuration signal/field tie-offs. 

These parameters can also be used by EDA vendors to create tools for automating mixing & matching of 
VCs and Buses, and by IP providers to document the setup of the VC. 

The default value of these parameters is 0 for all of the size/width type of parameters, and True for the 
binary type. 

Independent of the implementation model abstraction level, language or format, these parameters must be 
documented. The implementation of the parameters in the models can be done with generics (e.g. in an 
HDL), setup or header files, etc. In case of a configurable hard VC, some of these parameters may be 
implemented with external pins that can be tied-off. 'True* means high signal Yalue, and 'False' low signal 
value in the lists below. 



5.2.1 Parameters Specific to PVCI 



INITIATOR 
ADDRSIZE 
CELLS1ZE 
FreeBE 



True if VCI Initiator 

Address size, width of address bus in bits, range 0 to 31 

Cell size, number of bytes in the data bus, value 1,2 or 4 

True, if the VCI supports unrestricted combinations of byte enables. The 

restricted BE combinations, as defined in 3.4.3 must be supported by all VCI 

implementations. 

True, if component is big endian, False if little endian. 

True, if component does not care of endianness (e.g. a memory). Overrides the 
BIGEND1AN parameter. 

ACK is allowed to be asserted even when VAL is low (deasserted) 
"Number of clocks required of reset if NA or 0 use default (8 clocks) 
Number of error extension bits (defined as E), default is 0 



B1GENDIAN 
NOENDIAN 



DefACK 

RESETLEN 

ERRLEN 



5.2.2 Parameters Specific to BVCI 



INITIATOR 



True if VCI Initiator 

Initiator contains all signals and fields type MA and MI of table 5. 
Target contains all signals and fields of type MA of table 5. 
True if VCI is capable of packet chaining 

Chaining VCI contains all signals and fields of type MC of table 5. 

Cell size, number of bytes in the data bus 

Address size, width of address bus in bits 

CLEN size, width of CLEN field in bits 

True for big endian, False for Little endian 

True for VC which doesnt care of endianness 

CMDACK is allowed to be asserted even when CMDVAL is low (deasserted) 



CHAINING 



CELLSIZE 

ADDRSIZE 

CLENSIZE 

B1GENDIAN 

NOENDIAN 



DefCMDACK - 
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DefRSPACK - Initiator is always ready to acknowledge RSPVAL (initiator is not allowed to 

insert wait state). 

RESETLEN - Number of clocks required of reset if NA or 0 use default (8 clocks) 

ERRLEN - Number of error extension bits (defined as E), default is 0 



Default values for command extensions; for initiator the following parameters state that it will always send 
request of a certain behavior, as for target it only expects request of a certain behavior. The signal itself 
may or may not exist, but the behavior is known through these parameters, and the signals can be 
connected (tied off) accordingly. 



Dcfixed - signal cfixed is tied to High/Low 

Dconst - signal const is tied to High/Low 

Dcontig r signal contig is tied to High/Low 

Dwrap - signal wrap is tied to High/Low 



5.3 Implementation Guidelines 

Since the VCI is fully synchronous, and the wiring between the wrapper and a VC1 component is 
supposedly very short, the VCI implementation should be very easy to design. A legal VCI component 
must sample all the signals at rising edge of the CLOCK. To create a legal VCI bus wrapper for an OCB 
that samples at the falling edge of the clock, buffering registers must be added. 

The VCI standard should not pose any restrictions to making EDA tools that synthesize the bus wrapper 
automatically. This approach is preferred over manual wrapper design, since it reduces need for 
implementation verification, at least in theory. 

In register transfer level implementation of the VCI, there are few restrictions: The flip-flops inferred must 
be rising-edge clocked and have active-low reset. The VCI standard does not pose any other electrical 
constraints to the physical implementation than those timing constraints given in signal definitions. The 
VCI component provider must document the physical implementation parameters and constraints, such as 
voltage swings. The guidelines given in VSIA Implem en tation/Verifi cation DWG specifications and in On- 
Chip Bus DWG Attributes specification are to be followed. The manufacturing test constraints, or debug 
structures are not defined in the VCI standard. The guidelines given in VSIA Manufacturing Test DWG 
specifications are to be followed. 

In a case of partly or fully combinatorial wrapper, the delay paths starting and ending at VCI component . 
traverse all the way through the on-chip bus. It is the system integrator's responsibility to ensure the proper 
system timing in this case. 
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6. VCI Glossary of Terms 



VC Interface 

VCI Operation 
Cell 

Packet 

Packet Chain 

Signal 
Transaction 
Transaction Layer 

Initiator 

Target 

Bus Wrapper 
VC Wrapper 



An OCB standard virtual component interface to communicate between a bus 
and/or virtual component, which is independent of any specific bus or VC 
protocol. 

A VC operation is a transport object consisting of a pair of packets, which are 
transferred in different directions e.g. a single request-response packet pair. 

A cell is a grouping of one or more bytes. It contains a number of bytes that is 
characteristic to the natural width of the VCI implementation. It is the basic unit 
of information transferred across the VCI in one cycle. 

A packet is transport object consisting of an atomic ordered set of cells 
transferred across the VCL 

A packet chain is a non-atomic specialized transport object consisting of a set of 
logically connected packets transferred in the same direction across a VC 
Interface. The chain of packets is connected because no intervening packets are 
allowed on the same channel. 

Synonymous to electrical wire or net. 

Generic term used for any pair of request and response transfer. 

This deals with point to point transfers between blocks or virtual components. It 
does not define signal names, or clock-cycle protocols. 

A VC that sends request packets and receives response packets. It is the agent 
that initiates transactions e.g. DMA 

A VC that receives request packets and sends response packets. It is the agent 
that responds (with a positive acknowledgment by asserting) to a bus transaction 
initiated by a initiator - e.g. memory. 

Logic between the VCI and a bus. 

Logic between an existing VC and the VCI. 
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Claims 

1. An interface for communicating between electronic components 
having multiple connection points, said interface comprising: 

a circuit for a state machine to perform as a target and an initiator of a 
5 communication; and 

a plurality of pins, connected to the circuit, said plurality of pins 
corresponding to a set of target signals handling communication involving the 
component as a target and a set of initiator signals handling communication 
involving the component as an initiator. 

10 2. The interface of claim 1, wherein each of the plurality of pins are 

unidirectional and comprise at least one input pin and at least one output pin. 

3. The interface of claim 2, wherein the number of input pins is equal to 
the number of output pins. 

4. The interface of claim 3, wherein the set of target signals is symmetric 
1 5 with the set of initiator signals. 

5. An electronic component comprising: 

a circuit for a state machine to perform as a target and an initiator of a 
communication; and 

a plurality of pins, connected to the circuit, said plurality of pins 
20 corresponding to a set of target signals handling communication involving the 
component as a target and a set of initiator signals handling communication 
involving the component as an initiator. 

6. The electronic component of claim 5, wherein each of the plurality of 
pins are unidirectional and comprise at least one input pin and at least one output 

25 pin. 

7. The electronic component of claim 6, wherein the number of input 
pins is equal to the number of output pins. 

8. The electronic component of claim 7, wherein the set of target signals 
is symmetric with the set of initiator signals. 
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9. An integrated circuit comprising: 

(a) a bus; 

(b) a plurality of functional blocks; and 

(c) a plurality of ports, each port connecting the bus to one of the plurality 
5 of functional blocks; 

wherein each of the plurality of ports is designed to perform as both a target 
and an initiator of a communication. 



10. A computer-assisted model of an integrated circuit comprising: 

(a) a bus model; 
10 (b) a plurality of functional block models; and 

(c) a plurality of port models, each port model connecting the bus model 
to one of the plurality of functional block models; 

wherein each of the plurality of port models is designed to perform as both a 
target and an initiator of a communication. 

15 11. A method of designing an integrated circuit comprising the steps of: 

(a) specifying a communication block for the integrated circuit, including 
the locations of a plurality of androgynous interfaces; 

(b) identifying the functional blocks to comprise the integrated circuit; 

(c) positioning the blocks to form a layout of the integrated circuit to 
20 minimize connection distances between functional blocks and between functional 

blocks and the androgynous interfaces; 

(d) setting the androgynous interfaces to perform as targets or initiators 
based on the layout. 



25 



12. The method of claim 1 1, wherein the communication block is part of a 
specified foundation block. 
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